


Institutional Archive of the Naval Postgraduate School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1996-06 


Design and implementation of a NATOPS 
qualification database management system 
for Naval Aviation Safety Officers 


Martin, Terryll R. 


Monterey, California. Naval Postgraduate School 


http://ndl.handle.net/10945/32103 


Downloaded from NPS Archive: Calhoun 


Calhoun is the Naval Postgraduate School's public access digital repository for 


| (8 D U DLEY research materials and institutional publications created by the NPS community. 
«ist sha Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 


NY KNOX appointed — and published -- scholarly author. 

ia) LIBRARY Dudley Knox Library / Naval Postgraduate School 

411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 





http://www.nps.edu/library 





NAVAL POSTGRADUATE SCHOOL 
MONTEREY, CALIFORNIA 





THESIS 





DESIGN AND IMPLEMENTATION OF A NATOPS 
QUALIFICATION DATABASE MANAGEMENT SYSTEM 
FOR NAVAL AVIATION SAFETY OFFICERS 


by 
Terryll R. Martin 


June, 1996 


Hemant K. Bhargava 


Thesis Advisor: 





Approved for public release; distribution is unlimited. 


DTIC QUALITY INGPECTED S 





19960828 083 





REPORT DOCUMENTATION PAGE 


Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data 
sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other 
aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and 


Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) 
Washington DC 20503. 


1. AGENCY USE ONLY (eave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 
June 1996 Master’s Thesis 


4. TITLE AND SUBTITLE: DESIGN AND IMPLEMENTATION OF A NATOPS |5. FUNDING NUMBERS 
QUALIFICATION DATABASE MANAGEMENT SYSTEM FOR NAVAL 
AVIATION SAFETY OFFICERS 


6. AUTHOR: Terryil R. Martin 
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) PERFORMING 


















Naval Postgraduate School ORGANIZATION 
Monterey CA 93943-5000 REPORT NUMBER 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER jj. 








11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the 
position of the Department of Defense or the U.S. Government. 


12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE 
Approved for public release; distribution is unlimited. 


13. ABSTRACT (maximum 200 words) 

The VFA-125 Safety Office located at NAS Lemoore is burdened with the enormous administrative 
responsibility of managing the NATOPS qualifications for over 200 pilots and passengers. During this period of 
military downsizing and operational funding cuts, this responsibility will require the increased attention of a smaller 
staff with a limited budget. The burden of paper file management could be eased through the introduction of 
automated record keeping while simultaneously increasing accuracy and efficiency. The potential for a cae 
personnel to fly squadron aircraft could be eliminated. 

Based on VFA-125 Safety Office requirements, this thesis designs and implements a database management 
system. The primary objective is to automate the currently utilized manual NATOPS filing system to allow the 
squadron Safety Officer immediate access to all NATOPS-related pilot qualification data. This system will store, 
sort and compare data relevant to all squadron pilots while minimizing the time spent verifying the previously-used 
manual filing system. Additionally, the staff will be able to query reports and generate memoranda with minimal 
effort. The system is also analyzed to determine possible enhancements in the future. The Aviation Safety 
Database System is designed using dBASE III Plus and dBASE for Windows 5.0. 


SUBJECT TERMS: Database Implementation Database Management System NATOPS | 15. NUMBER OF 
Qualification Tracking System | PAGES 102 


16. PRICE CODE 


SECURITY CLASSIFICA- . SECURITY CLASSIFI- 19. SECURITY CLASSIFICA- | 20. LIMITATION OF 
TION OF REPORT CATION OF THIS PAGE TION OF ABSTRACT — ABSTRACT 


Unclassified Unclassified Unclassified oer UL 


NSN 7540-01-280-5500 | | Standard Form 298 (Rev. 2-89) 
| Prescribed by ANSI Std. 239-18 298-102 


. DTIC QUALITY INSPECTED 8 














Approved for public release; distribution is unlimited. 


DESIGN AND IMPLEMENTATION OF A NATOPS 
QUALIFICATION DATABASE MANAGEMENT SYSTEM 
FOR NAVAL AVIATION SAFETY OFFICERS 


Terryll R. Martin 
Lieutenant Commander, United States Navy 
M.S., Naval Postgraduate School, 1990 
B.S., University of Arizona, 1980 


Submitted in partial fulfillment 
of the requirements for the degree of 


MASTER OF SCIENCE IN MANAGEMENT 
from the 


NAVAL POSTGRADUATE SCHOOL 


| June 1996 
| | Terryll R. Martin 





Hemant K. Bhargava, Thesis Advisor 



















-{/ 


- Douglas E. Brinkléy, LCDR, SC USNS second Reader 


/} Reuben T. Harris, Chairman 
epartment of Systems Management 





D 





ili 








1V 

















ABSTRACT 


The VFA-125 Safety Office located at NAS Lemoore is burdened with the 
enormous administrative responsibility of managing the NATOPS qualifications for 
over 200 pilots and passengers. During this period of military downsizing and 
operational funding cuts, this responsibility will require the increased attention of a | 
_ smaller staff with a limited budget. The burden of paper file management could be 
eased through the introduction of automated record keeping while simultaneously 
increasing accuracy and efficiency. The potential for non-qualified personnel to fly 
squadron aircraft could be eliminated. 

Based on VFA-125 Safety Office requirements, this thesis designs and 
ee a database management system. The primary ebiecae is to automate the 
currently utilized manual NATOPS filing system to allow the squadron Safety Officer 
immediate access to all NATOPS-related pilot qualification data. This system will 
store, sort and compare data relevant to all squadron pilots while minimizing the time 
spent verifying the previously-used manual filing system. Additionally, the staff will 
_ be able to query reports and generate memoranda with minimal effort. The system 
is also analyzed to determine possible enhancements in the future. The Aviation 
Safety Database System is designed using dBASE III Plus and dBASE for Windows 


5.0. 
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I. INTRODUCTION 


A. OBJECTIVE 

This thesis designs and implements a database system for the Aviation Safety 
Department of U. S. Navy Strike Fighter Squadron 125 (VFA-125). The purpose of the 
system is to manage the Naval Air Training and Operational Procedures Standardization 
(NATOPS) qualifications of every individual who occupies a seat of a VFA- 125 aircraft. 
Successful implementation of the database system would assist the squadron's Aviation Safety 
Officer (ASO) in his effort to ensure that only fully NATOPS-qualified personnel fly in 
squadron aircraft and would significantly reduce the time spent by Safety Department 
personnel in manually tracking each individual's multiple NATOPS qualifications, The 
database design takes into consideration each of VFA-125's NATOPS-related functional 
requirements. The siiiaty function of the database system is to maintain the NATOPS 
record of each squadron aircraft occupant and to act as a repository for additional relevant 
data. From this database, standard reports are generated while ad hoc queries and reports are 
easily created. 
B. BACKGROUND 

VFA-125, the U. S. Navy's west coast F/A-18 Fleet Replacement Squadron (FRS), 
is located at Naval Air Station (NAS) Lemoore, California. As one of two F/A-18 FRSs, 

VFA-125 is responsible for the training of ne 100 Fleet Replacement Pilots (RPs) each year. 

To accomplish this goal, the squadron requires the services of approximately 75 F/A-18 


Instructor Pilots (IPs) and over 40 F/A-18 and T-34 aircraft. Additionally, because nearly 
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half of VFA-125's training aircraft contain two seats (all other NAS Lemoore F/A-18 
squadrons utilize only single seat aircraft), the squadron is tasked with providing backseat 
siaseative flights to other squadron's enlisted military personnel, nonmilitary media personnel 
as well as high-ranking domestic and foreign government officials. 

Each individual who occupies a seat of an F/A-18 or T-34 aircraft (with the intent of 
flight) must be fully qualified in accordance with OPNAV Instruction 3710.7Q [Ref. 1]. 
Because the qualification for flight requirements vary or on the aircraft occupant's 
flight-related duties, it is the squadron's ASO who is charged with verifying the NATOPS 
flight status of every potential aircraft occupant prior to aircraft entry. Should an unqualified 
individual occupy a squadron aircraft and an accident occur, the ensuing Judge Advocate 
General investigation could find the squadron's Commanding Officer responsible for lack of 
oversight. 

The VFA-125 Safety Department includes the ASO, the NATOPS Officer, the 
Ground Safety Officer, the Model Manager, the Aviation Safety Petty Officer (ASPO) and 
various administrative support personnel. The ASO acts as the squadron Safety Department 
Head and, in concert with the NATOPS Officer and ASPO, continuously monitors the status 
of ath individual's NATOPS qualifications. Prior to database system implementation, 
tracking of NATOPS qualification paperwork was haphazard and time intensive. NATOPS 
records were kept in file drawers and NATOPS documents were filed at random intervals. 
A NATOPS cover sheet was maintained inside each NATOPS jacket and annotated as 


changes occurred. To verify NATOPS qualifications, each jacket was individually pulled and 








its multiple documents carefully scrutinized. As a result, it was not uncommon for individuals 
to fly in squadron aircraft with expired NATOPS qualifications. 

To assist the reader in the ensuing description of database system design and 
implementation, the following are some brief explanations of terminology as related to naval 
aviation in general and VFA-125 in particular: 

Aircraft Occupant is any individual who occupies any seat of a VFA-125 F/A-18 or 
T-34 aircraft. The front seat must be occupied by a designated IP or RP. The aft seat may 
be occupied by an IP, RP, Naval Flight Officer (NFO), Flight Surgeon, Flight Physiologist or 
Selected Passenger. 

Designated Airerew include all personnel who are in a flight status. In VFA-125, this 
encompasses IPs, RPs, NFOs, Flight Surgeons and Flight Physiologists. [Ref. 1: p. 1-3] 

Flightcrew include those aircrew who perform crew functions on board the aircraft 
in support of the assigned mission. These personnel include IPs, RPs and NFOs. Ref 1: p. 
1-5] 

Selected Passengers are those aircraft occupants who are not designated as aircrew 
and who perform no official flightcrew duties. Because VFA-125's F/A-18s are equipped 
with ejection seats and is T-34s are equipped with personal oxygen systems, all passengers 
in squadron aircraft must be NATOPS qualified. [Ref. 1: p. 1-7] 

Flight Physicals are required for all aircrew on an annual basis. The flight physical 
may be initiated the month prior to the birth month but no later than the last day of the birth 


month. Failure to initiate a flight physical results in mandatory suspension of flight duties. 











Flight physicals for selected passengers are also mandatory and are valid for one year from 
date of issue. [Ref. 1: pp. 8-12, 8-20] 

Water Survival Training is mandatory for all aircrew and remains valid for four years. 
7 Water survival training is required for selected passengers but has a duration of 36 months. 
[Ref. 1: pp. 8-17, 8-18] 

Flight Physiology Training is mandatory for all aircrew and, like water survival 
training, remains valid for four years. Physiology and water survival training usually are 
scheduled in tandem but they may occur at separate times. Flight physiology training is 
mandatory for selected passengers and remains valid for three years. [Ref. 1: p. 8-15] 

Emergency Egress Training is mandatory for all aircraft occupants. In VFA-125, 
ejection seat training is required for F/A-18 occupants and bailout training is required for 
flight in T-34 aircraft. In each case, training is valid for twelve months from the last day of 
the month in which the training occurred. [Ref. 1: p. 8-10] 

Instrument Ratings/Qualifications are mandatory for all pilots/NFOs who perform 
flight duties. These instrument ratings are valid for one year from the end of the month in 
which qualification occurred. Only one.instrument rating/qualification is required even if a 
pilot/NFO is qualified to fly multiple aircraft types. A pilot's failure to maintain a valid 
instrument rating will result in his appearance before a field naval aviation evaluation board. 
[Ref. 1: pp. 13-1, 13-3] 

NATOPS Evaluations ensure that aircrew ‘indietieand = rn with each aircraft's 
standard operating procedures. They are mandatory for all pilots/NFOs who perform flight 


duties and are required for each type of aircraft flown. In VFA-125, a pilot could have 
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NATOPS qualifications in both the F/A-18 and T-34. These evaluations are valid for twelve 
months from the end of the month in which the evaluation is performed. [Ref. 2: p. 10-1, Ref. 
3: p. X-22-1] 

‘NATOPS Manuals provide written descriptions of aircraft standard operating 
procedures. Each pilot/NFO is issued a set of these manuals. — of the large number 
of aircrew assigned to VFA-125, the squadron's Safety Department maintains over 1000 
NATOPS manuals. It is the ASO's seaponsbility to ensure that issued manuals are returned 
upon a pilot's or NFO's departure from VFA-125. 

. AVIATION SAFETY DATABASE SYSTEM 

“The Aviation Safety Database System (ASDS) was designed to reduce the ASO's 
time-intensive NATOPS qualification verification process and reduce the administrative | 
NATOPS qualification tracking burden on the ASO's Safety Department personnel sails 
_ making the storage and retrieval of critical information more timely and efficient. 
Additionally, the ability to quickly sort through the entire squadron's NATOPS qualification 
records significantly reduces devine required to build and disseminate needed reports. To 
accomplish this increase in efficiency, an in-depth study was viliiiesa on the needs of the 
VFA-125 ASO and his department. 

: Because the VFA-125 Safety Department was equipped solely with a Zenith 248 
computer, the ASDS was originally built utilizing Ashton-Tate's dBASE III Plus. Since 
ASDS completion, the Safety Department has acquired a Windows-capable IBM compatible 
personal computer (PC). The ASDS has diese maditied 46 operate effectively in Borland's 


dBASE for Windows version 5.0. Many iterations and revisions of the ASDS were 











accomplished through continuous reassessment of VFA-125's NATOPS program and 
recommendations from both the ASO and ASPO. ASDS is menu driven and designed for 
ease of use by those personnel unfamiliar with either databases in general or dBASE in 
. particular. 
D. CHAPTER DESCRIPTIONS 

Chapter II is a general description of the database development methodology 
considered in developing the VFA-125 NATOPS qualification automated information system. 

Chapter III will discuss the ASDS application development process and the phases 
discussed above. 

Chapter IV will discuss conclusions and recommendations. This chapter will provide 
a short summary of the thesis, identify future ASDS enhancements and possible areas for 

system growth. 
Appendices A through G provide supporting diagrams and documentation to the 

previously described text.. The appendices include the ASDS entity-relationship model, 
semantic object model, relational model, data dictionary, menus and forms, reports and 


| dBASE source code. 


























I. DATABASE APPLICATION DEVELOPMENT - GENERAL 


The ASDS was developed using the five standard phases of the Systems Development 
Life Cycle (SDLC). These five phases include the definition phase, requirements phase, 
evaluation phase, design phase and implementation phase. This chapter will discuss the 
generic requirements of each phase. [Ref. 4: pp. 672-683] 
A. PHASE I: DEFINITION PHASE 

i. Form Team 

In essence, the definition phase determines what a database system will do. The initial 

action is to form a working team of individuals who will build the database system. Special 
attention should be paid to each team member's strengths and level of previous experience. 
The team should be nan enough to accomplish all associated tasks but not so large as to 
unduly influence the overall developmental process. [Ref. 5: p. 3] 

2. Define Problem | 

Once team formation is complete, the problem to be solved must be defined. A 
problem is a perceived difference between what is and what ought to be. Since problems are 
perceptions, each individual's definition of the problem may vary. greatly. The team must 
_ reach some agreement as to the problem's definition as well as establish the criteria for a 
successful solution. [Ref. 5: p. 3] 
3. Establish Scope 
Establishing the scope of the problem is defining the limitations of how the team can 


help solve a specific portion of the defined problem. The system's ultimate users may desire ~ 





too many features or possibly too few. The task of defining the scope establishes proposed 
parameters for both developers and users. [Ref. 5: p. 3] 

4. Assess Feasibility 

Once the system development team has been formed, the problem completely defined 
and the scope established, it is necessary to determine the overall feasibility of the entire 
project. Areas to consider are Cost, time and schedule requirements. Upon definition phase 
conclusion, the database system development team should ee back to the end user for 
feedback. Improvements and revisions can be made at this time. [Ref. 5: p. 4] _ 
B. PHASE I: REQUIREMENTS PHASE 

1. Create Data Model 

A requirements phase is necessary to build on the specifics laid out in the definition 
phase. The expansion of the definition phase is done through employment of the user's 
requirements and data models. The user's data model describes the objects that are to be 
stored in the database and denotes their relationship to one anotlier as well as their overall 
structure. The requirements data model represents the basis for database design.. The model 
should be a "macro view" of the input documents, processes required and the sence output 
desired 5 the ultimate user. [Ref. 5: p. 4] 

2. Determine Update, Display and Control Mechanisms 

Within the requirements phase, it is necessary to establish functional components or 
mechanisms to update, display and control the database. These mechanisms will define the 
means by which the user will maintain a current database and retrieve useful information from 


it. [Ref. 5: p. 4] 














3. Interview Users _ 

Users are always the ultimate authority on system application requirements. The 
development team will use its experience, background and knowledge to assist users in the 
proper formulation of their requests regarding system inputs; outputs and constraints. The 
team must also help the users set achievable goals based on plausible user needs. [Ref. 5: p. 
4] 

4, Use Prototypes 

Mock-ups of forms, reports and menus can be developed to help users envision the 
future product. The purpose of these prototypes is to open an avenue for dialogue between 
team members and users. With candid fexdback the development team may be able to extract 
additional sequirenients from the users and further refine the system in its early stages. 

The result of we phase could be a data-flow diagram, an entity-relationship diagram, 
a semantic object diagram, various prototypes, a summary of update, display and control 
mechanisms or any combination of these. [Ref. 5: p. 5] 

C. PHASE Ill: EVALUATION PHASE 

1. Select Systems Architecture 

The evaluation alias begins after all the data collected in the requirements phase is 
compiled and considered. During this phase, a systems architecture should be selected and 
alternatives should be considered ie ensure the ideal match is made for the user. The system 
initially selected may be excluded due to new information exposed in the requirements phase. 


[Ref. 5: p. 5] 





2. Reassess Feasibility 

After deciding the specifics of the hardware to be used, a Saeseranialll of its feasibility 
should occur. This reassessment should be more specific than that considered in the definition 
phase. During the reassessment, considerations should include expenses, overall scope and 
timing as well as any new requirements. [Ref. 5: p. 5] 


3. Reassess Requirements 


If it appears that anticipated solutions to any of the evaluated areas cannot be achieved 


by the development team, the users should be notified and an effectively implemented 
feedback loop should ensure that the overall project becomes achievable. Required revisions 
may be as simple as an adjustment to schedules, tweaking the budget or a larger reduction in 
physical specifications. Another consideration may be the possible deferral or exclusion of 
actions. [Ref. 5: pp. 5-6] 
D. PHASE IV: DESIGN PHASE 

1. Develop Database Design 

Application and database design will take place within the design phase. Here the task 
is to meet the users’ specific needs through designed programs and eae ee specifications 
_ for hardware are also written during this phase. Files are established (relation tables), data 
items (attributes) are defined and relationships are correlated between objects. Relationships 
between objects can be simply one-to-one, one-to-many or a more complex many-to-many. 
Normalization should be conducted to ensure that there are no anomalies between relations. 


Elimination of anomalies occurs by splitting the relation into two or more separate relations, 
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each containing a single theme. Objects may be a basic, simple object or a grouping of 
objects called an aggregation. [Ref. 5: p. 6] 

2 Develop Application Design 

Within the design phase, the database and applications are created. An application 1S 
a collection of menus, forms, reports and queries that enable users to interact with and update 
the system. Mechanisms by which the system is to be implemented and updated will be 
developed and the program's logic will be decided. This is the ideal time to detect errors prior 
to building the system. Beyond this point, finding errors will be difficult and correcting them 
arene, 

The output of this design phase could include a relation diagram, relation definitions, 
menu hierarchy and pseudo code for each menu and sub-menu. [Ref. 5: p. 6] 
E. PHASE V: IMPLEMENTATION | 

1. Construct Database 

The final phase is implementation. The task is ” build the system according to the 
specifications decided up to this point. Users' needs must be isolated at this juncture. Any 
- further requirements will elaatiaie affect the system's development. Programming usually 
occurs ‘ this point. Using the data definition subsystem of the engineered database 
management system (DBMS), the design is converted to fit the user's requirements. The goal | 
is to construct the system while strictly adhering to the design. Hardware is installed, 
sia are developed, procedures are decunenied arid office staff and users are trained. 


[Ref. 5: p. 7] | 


11 








2. Build Application 

Forms, reports and menus need to be built through application development as well 
as construction of transaction processing programs. [Ref. 5: p7] 

3. Testing 

An often ignored area of implementation is testing. Testing verifies that any errors 
which may have been created in the modeling or implementation phases are discovered and 
that the system performs those functions as designed by the user. This testing can be 
accomplished in a number of ways. The testing should not be isolated to a specific phase; 
rather it should be distributed throughout the entire project ” it progresses. The types of 
testing vary greatly depending on the complexity of the system and its developers. [Ref. 5: 
p. 7] 

4. Installation 

Installation is one of the final steps in implementation. Installation can occur in either 
of four strategies. The first of these is the parallel strategy whereby both the old and new 
systems operate side by side until it is proven that the new iii is working properly. The 
_ second is the pilot strategy where only a small piece of the function or office is converted to 
the new system. The new system operates in one se with the old system remaining in place 
until conversion occurs at a later date. Phase-in is the third strategy. Here, the old system 
is gradually replaced by the new system. The final strategy is direct cutover. Complete 
conversion takes place immediately upon system availability with the a system replacing 


the old all at once. 
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User and operator guides and documentation are generated as well in this phase. 
Training is recommended to ensure a smooth transition from the old system to the new one. 
The training should be complete such that users and system administrators are familiar with 
what the system can and will do for them. [Ref. 5: pp. 7-8] 

= Maintenance 

Maintenance requires the verification of three areas: 

® Correction of errors discovered during system operation. 

@ iiplemeriation of modifications to the system due to user requests or changes in 
requirements after implementation. 

© The implementation of performance enhancements and improvements to user 
interfaces. 

It is umportant to maintain the system with minimal disruption to the users; therefor, 
a "high degree of independence" is desired so as to insulate applications from the physical 


organization of the database. [Ref. 5: p. 8] 
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If. SYSTEM DEVELOPMENT - ASDS 


A. PHASE I: ASDS DEFINITION PHASE 

The development team consisted of the author, the VFA-125 NATOPS Officer and 
the VFA-125 ASPO. The saistiont NATOPS Officer and ASPO were selected as team 
members due to their in-depth knowledge of the Safety Office's business rules; particularly 
their familiarization with OPNAV 3710.7Q [Ref. 1]. 

The fundamental problem experienced by the squadron's Safety Office was the 
tracking of mandatory NATOPS-related qualifications for all squadron aircraft occupants. 
The Safety Office's manual NATOPS qualification tracking system required the ASPO and 
his assistants to file NATOPS-related qualification forms in each aircraft rider's NATOPS 
Flight Personnel Training/Qualification Jacket. Once — NATOPS qualification forms were 
entered in the Qualification Jacket, the Jacket's NATOPS Qualification Certification page was 
annotated with the change and the Jacket was replaced in its filing cabinet. Unless there was 
a specific reason to pull a particular NATOPS Jacket, no one regularly ensured that each 
aircraft occupant was fully NATOPS qualified until a quarterly review was completed. It was 
— these reviews that many NATOPS aniaiiicatcn were discovered to be expired. It was 
the desire of the squadron ASO to implement a DBMS which would allow Safety Department 
personnel to track each aircraft occupant's NATOPS qualifications on a daily basis. The 
ultimate goal was to eliminate the possibility of any unqualified individual becoming airborne 


in a squadron aircraft. 
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In Addition, the hours expended by the Safety Office's staff in tracking the volumes 
of NATOPS-related paperwork were excessive. With the continuing trend towards 
downsizing in today's Navy, the ability to increase oversight of the NATOPS qualification 
tracking program while simultaneously reducing manpower requirements greatly increased 


the ASO's interest in the benefits. of DBMS implementation. 


As a result, the ASO requested that a feasibility study be initiated to design a DBMS" 


that could be updated on a daily basis, be maintained by the ASPO and his assistants, be 
available to all Safety Office personnel, ensure security of NATOPS-related information and 
be installed on a single IBM compatible 286 PC. | 

The scope of the project was to construct a DBMS that could track the numerous 
NATOPS forms required to ensure that an individual was qualified to fly in a squadron 
aircraft. If this NATOPS-related information could be stored in conjunction with associated 
data regarding each aircraft occupant's military service, the task of managing this information 
could be made much more efficient. Reports could be generated automatically and thus 
greater emphasis could be placed on managing each aircraft occupant's NATOPS qualification 
situation rather than merely ie to it. 

The goal of Safety Office DBMS implementation was to track information in the 
following major areas: 

@ Egress training 

° Flight physicals 

® Flight physiology | 


® Water Survival 
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@ Antmal NATOPS evaluations 

@ Annual Instrument ratings/qualifications 

@ NATOPS manual assignments 

No additional funding was available for Safety Department DBMS implementation. 
As a result, no additional hardware or software purchases were authorized. The then 
available 286 IBM compatible PC included dBASE III Plus as the only available database _ 
application. At the time of ASDS project initiation, a request was made by the ASO for a 
second, upgraded 486 PC utilizing the Windows operating system. 

The many benefits of ASDS implementation included: 

® Reduction in man-hours by the introduetion of automation. 

e Time savings for Safety Department staff to perform other office functions due to 
the more efficient retrieval of NATOP S-related data. 

© Data entries could be more easily reviewed resulting in rapid verification and 
greater data integrity. 

@ Increased ability to sort, query and conduct analysis of stored data. 
B. PHASE I: ASDS REQUIREMENTS PHASE 

| Prior to initiation of ASDS design, a decision regarding database development style 

and schema design was required. The options included the top-down, bottom-up, inside-out 
and mixed strategies. The inside-out strategy was selected because the order of refinements 
is disciplined (as in the top-down approach) however, this strategy allows the most evident 


concepts to be fixed first with subsequent navigation toward more distant ones. This strategy 


17 











allowed Aircraft Occupant to be identified as the driving factor in modeling the ASDS. [Ref. 
6: pp. 66-76] 

The main objective of those Safety Department personnel interviewed was to identify 
and automate the minimum NATOPS-related information required to ensure that no one flew 
in a squadron aircraft while not fully qualified. In addition, the rapid entry and retrieval of 
each aircraft occupant's NATOPS-related data was desired. Interviews were conducted with 
each potential Safety Department ASDS user. Those interviewed were the NATOPS Officer, 
the ASPO and each Safety Department clerk. ASDS-related discussion items were geared 
toward improving overall office efficiency. Due to the a intensive manual filing 
system, aircraft occupant information was often difficult to locate or impossible to aay 
in a timely fashion. Unless a NATOPS Jacket was pulled and each qualification form 
scrutinized, no central information system was sic to identify “out-of-qual" personnel. | 
No back up files existed. Additionally, no information distribution system was in place to 
notify squadron personnel that they wee no longer NAT Ops qualified or soon would not be. 
As a result, the squadron's Schedules Officer could not preplan NATOPS qualification flights 
or classes in oe 

The Safety Department staff requested the following reports: — 

@ NATOPS qualification expiration report. — 

— @ List of authorized NATOPS qualified passengers. 

Utilizing the experience of the ASO, NATOPS Officer and ASPO, further user 

requirements were developed by; (1) determining which NATOPS-related forms were most 


often employed and (2) examining the properties of desired Safety Office recurring reports 
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with particular emphasis on increasing overall department efficiency. Safety Department use 
of current NATOPS qualification forms is mandated by OPNAV 3710.7Q. Despite multiple 
redundancies located throughout these required NATOPS forms, the ASDS was created to 


streamline their completion and subsequent data entry into the DBMS. The new ASDS- 


generated NATOPS qualification report formats were constructed for both their ease of use mee 


and potential for rapid information dissemination. 

Through multiple interviews with Safety Office personnel, scrutiny of individual 
NATOPS Training Jackets and : study of OPNAV 3710.7Q, the design team developed two 
data models. The first was the entity-relationship (E-R) model, the second was the semantic 
object model (SOM). Because of the team's inside-out strategy of schema design and the 
strategy's combination of top-down (E-R related) and bottom-up (SOM related) database | 
design approaches, both types of data models were constructed. A discussion of ae model 
as it applies to the ASDS follows. The E-R model is displayed in Appendix A; the SOM 
_ appears in Appendix B. _ 

1. The ASDS Entity-Relationship Model 

Through numerous discussions with Safety Office personnel, the following 18 entities 
were identified as central to the NATOPS qualification tracking evolution: 

© SQUADRON AIRCRAFT OCCUPANT 

© DESIGNATED AIRCREW (NON-FLIGHTCREW) 

e DESIGNATED AIRCREW (FLIGHTCREW) 

_@ SELECTED PASSENGER 


e FLIGHT SURGEON 
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e FLIGHT PHYSIOLOGIST 

® INSTRUCTOR PILOT 

® REPLACEMENT PILOT 

® EGRESS TRAINING 

e FLIGHT PHYSICAL 

@ 48 MONTH FLIGHT PHYSIOLOGY 

e 48 MONTH WATER SURVIVAL 

@ 36 MONTH FLIGHT PHYSIOLOGY 

© 36 MONTH WATER SURVIVAL 

© ANNUAL NATOPS EVALUATION 

@ ANNUAL INSTRUMENT RATING 

@ NATOPS MANUALS 

e CLASS 

The SQUADRON AIRCRAFT OCCUPAN r entity is central to the E-R model 
because only one individual can occupy any given seat in a squadron aircraft. This entity has 
three subtypes: DESIGNATED AIRCREW (NON-FLIGHTCREW), DESIGNATED 
AIRCREW (FLIGHTCREW) and SELECTED PASSENGER. These subtypes are mutually 
exclusive indicating that each SQUADRON AIRCRAFT OCCUPANT entity must belong to 
only one subtype. | 

The ASDS E-R model indicates that the entities FLIGHT SURGEON and FLIGHT 
PHYSIOLOGIST are mutually exclusive subtypes of DESIGNATED AIRCREW (NON- 


FLIGHTCREW). These entities represent personnel designated as aircrew who perform no 
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airborne flightcrew duties. The entities INSTRUCTOR PILOT and REPLACEMENT 
PILOT are mutually exclusive subtypes of supertype DESIGNATED AIRCREW 
(FLIGHTCREW). Members of these subtypes actually perform required flight duties while 
airborne. The subtype SELECTED PASSENGER represents those SQUADRON 
AIRCRAFT OCCUPANTS who are neither designated as aircrew nor perform any flight 
duties. 

SQUADRON AIRCRAFT OCCUPANT has a relationship with EGRESS 
TRAINING, FLIGHT PHYSICAL and NATOPS MANUALS. The maximum cardinality 
of the EGRESS TRAINING relationship is 1:N because an individual may receive egress 
training in both the T-34 and F/A-18 aircraft. FLIGHT PHYSICAL's existence is dependant 
on and therefor is a weak entity of SQUADRON AIRCRAFT OCCUPANT. Each 
SQUADRON AIRCRAFT OCCUPANT must have one FLIGHT PHYSICAL. NATOPS 
MANUALS has a 1:N relationship with SQUADRON AIRCRAFT OCCUPANT because 
some SQUADRON AIRCRAFT OCCUPANT’ are issued no NATOPS MANUALS while 
others are issued many. | 

Each SELECTED PAS SENGER has a 1:1 relationship with 36 MONTH FLIGHT | 
PHYSIOLOGY and 36 MONTH WATER SURVIVAL. DESIGNATED AIRCREW (NON- 
FLIGHT CREW) and DESIGNATED AIRCREW (FLIGHTCREW) have a 1:1 relationship 
with 48 MONTH FLIGHT PHYSIOLOGY and 48 MONTH WATER SURVIVAL. No one 
may become airborne in a Navy aircraft without these qualifications. 

ANNUAL NATOPS EVALUATION is sesehduns upon and therefor a weak entity 


of both INSTRUCTOR PILOT and REPLACEMENT PILOT. Because INSTRUCTOR 
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PILOTs may have an ANNUAL NATOPS EVALUATION in both the T-34 and the F/A-18, 
the relationship between these two entities is 1:N. The relationship between 
REPLACEMENT PILOT and ANNUAL NATOPS EVALUATION is 1:1 because 
REPLACEMENT PILOTS receive an ANNUAL NATOPS EVALUATION only in the F/A- 
18 aircraft. 

The entity CLASS has a 1:N relationship with REPLACEMENT PILOT and a N:-M 
relationship with INSTRUCTOR PILOT. This occurs because each REPLACEMENT 
PILOT must be assigned to a class. Each CLASS consists of multiple REPLACEMENT 
PILOTs and is instructed by multiple INSTRUCTOR PILOTS. While some INSTRUCTOR 
PILOTs may teach multiple CLASSes, other INSTRUCTOR PILOTs may have no affiliation 

with any CLASS. 7 | 
. 2 The ASDS Semantic Object Model 

During development of the ASDS SOM, several opportunities were discovered 
whereby previously identified ASDS E-R entities could be combined with no discernable 
reduction in overall ASDS utility. The following 11 objects were identified: 


e AIRCRAFT RIDER 


FLIGHTCREW 


PASSENGER 


EGRESS 


PHYSICAL 


SWIM | 


PHYSIOLOGY 
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INSTRUMENT QUAL — 


NATOPS EVAL 
_@ MANUALS 

® CLASS 

AIRCRAFT RIDER is a parent/subtype semantic object with unique identifier SSN. 
Additional simple attributes include Name, RankRate, Grade, Service, Designator, BirthDate 
and BirthMonth. These attributes are routinely found on every NATOPS form. On the 
ASDS SOM diagrams, simple attribute cardinalities are omitted when the identifying 
attributes have a cardinality of 1.1 and the other simple attributes have a cardinality of 0.1. 

AIRCRAFT RIDER also contains the object attributes EGRESS, PHYSICAL, 
_ SWIM, PHYSIOLOGY and MANUALS. The cardinality of EGRESS is 1.N because an. 
AIRCRAFT RIDER may receive EGRESS training in both the T-34 and F/A-18 aircraft. The 
cardinalities of PHYSICAL, SWIM and PHYSIOLOGY are 1.1 because each is mandatory 
for every AIRCRAFT RIDER. MANUALS cardinality is O.N because an AIRCRAFT 
RIDER may be issued many or no MANUALS. 

FLIGHTCREW and PASSENGER are subtype objects of AIRCRAFT RIDER 
denoted by the subscript 0.ST. This subtype group's subscript 1.1.1 indicates that the subtype 
is required and exactly one of the subtypes must exist. Therefor, every AIRCRAFT RIDER 
is either FLIGHTCREW or a PASSENGER. This is a change from the E-R model in that the 
SOM includes entities FLIGHT SURGEONS and FLIGHT PHYSIOLOGISTS as 
PAS SENGERS and FLIGHTCREW combines the entities INSTRUCTOR PILOT and 


REPLACEMENT PILOT. 
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The FLIGHTCREW subtype object inherits supertype object AIRCRAF T RIDER's 
attributes. Object FLIGHTCREW identifies object AIRCRAFT RIDER as its parent with the 
subscript P. FLIGHTCREW also contains the object attributes INSTRUMENT QUAL, 
NATOPS EVAL and CLASS. The cardinality of INSTRUMENT QUAL is 1.1 because each 
FLIGHTCREW must have one INSTRUMENT QUAL. Because each FLIGHTCREW must 
have a NATOPS EVAL for each type aircraft flown, the cardinality of NATOPS EVAL is _ 
1.2. The cardinality of class is 0.N because a FLIGHTCREW IP may teach multiple classes 
or none at all while an RP must belong to exactly one class. 

PASSENGER is a subtype object and inherits the attributes of supertype object 
AIRCRAFT RIDER. Since PASSENGERs may be military or civilian with no required VFA- 
125 billet, the simple attributes Location, Billet and PhoneNumber allow each PASSENGER 
to be inaiaal by Safety Office personnel if necessary. 

The EGRESS compound object contains the unique identifier SSN as well as the 
simple attributes Name, RankRate, TypeSeat, InstructionDate, Grade, Unit.and Instructor. 
EGRESS also includes the object attribute AIRCRAFT RIDER which has a 1.1 cardinality 
because each EGRESS event is associated with only one AIRCRAFT RIDER. | | 

PHYSICAL is a compound object with the unique identifier SSN. Additional sanple 
attributes include Name, RankRate Service PhysicalDate and PhysicalExpiration. The object 
attribute AIRCRAFT RIDER is an object identifier of PHYSICAL with a cardinality of 1.1. 
Each instance of PHYSICAL must correspond directly with each AIRCRAFT RIDER. 
cou | The compound objects SWIM and PHYSIOLOGY both contain the nade identifier 


SSN and simple attributes Name, RankRate, Category, InstructionDate, Grade, Unit and 
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Instructor. Object attribute AIRCRAFT RIDER has a cardinality of 1.1 because each event 
of SWIM and PHYSIOLOGY is directly associated with each AIRCRAFT RIDER. 

The object INSTRUMENT QUAL has unique identifier SSN and simple attributes 
Name, Rank, Unit, Rating, DateOfCheck, ExpirationDate, Examiner and Issuer. The 1.1 
cardinality of object attribute FLIGHTCREW indicates that each instance of INSTRUMENT 
QUAL corresponds with a FLIGHTCREW member. 

Object NATOPS EVAL contains unique identifier SSN and simple attributes Name, 
Rank, Squadron, AircraftModel, CrewPosition, FlightHours, Evaluator and DateOfEval as 
well as object attribute FLIGHTCREW. The cardinality of FLIGHTCREW is 1.1 indicating 
that each NATOPS EVAL corresponds directly with each FLIGHTCREW. 

The compound object CLASS includes unique identifier ClassNumber, simple 
attributes StartDate, PhaseDate, NumberStudents, DetachmentDate, GraduationDate and 
object attribute FLIGHTCREW. Each Replacement Pilot (a separate entity in the E-R model 
but a member of FLIGHTCREW in the SOM) is assigned to only one CLASS resulting in 
FLIGHTCREW's 1.1 cardinality. 

The compound object MANUALS contains group identifier ManualID which includes 
attributes ManualType and ManualNumber. Despite the fact that VFA- 125's Safety Office 
controls over 1000 NATOPS manuals, each can be identified by the combination of 

ManualType and ManualNumber. The object attribute AIRCRAFT RIDER has a cardinality 
of 0.1 indicating that an individual manual may be ere in the Safety Office or issued to only 


one AIRCRAFT RIDER. 
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C. PHASE IIT: ASDS EVALUATION PHASE 

At the start of the ASDS project, the Safety Office's only available computer system 
was a 286 IBM compatible PC. During the latter stages of the project, a 486 IBM compatible 
PC was procured. It was the ASO's desire to utilize the 286 PC for database management 
and the 486 PC for all other Safety Department administrative functions. To ensure 
continuous ASDS availability, it was decided that the ASDS should be operable on both 
machines. Because dBASE II Plus and dBASE for Windows are compatible, this request 
was achievable with minimum modifications to the dBASE source code. ASDS-related 
design and implementation required no funding. The ASPO would be trained to maintain the 
database ten Additionally, it was decided that the ASDS should have a daily back-up 
| capability to ensure database information integrity. 

A complete feasibility reassessment was conducted during this shaw Both the ASO 
and ASPO studied the entity-relationship and semantic object models. After considerable 
discussion, the ASO decided that more information was contained in the models than was 

actually required for use by the squadron's Safety Office. The ASO's minimum NATOPS 
tracking requirements were the expiration dates of each qualification. Thus, the obj ect 
EGRESS could be replaced with attribute EgressExpiration, PHYSICAL with 
PhysicalExpiration, SWIM with SwimExpiration etc. Since there were exactly ten NATOPS 
manuals, each with a different name, the object MANUALS could be replaced by ten 
individual attributes. If practical, it was the ASO's desire to simplify the database into the 
fewest possible but distinct tables which would continue to allow the minimum data input for 


all squadron flightcrew and passengers. 
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D. PHASE IV: ASDS DESIGN PHASE 

In response to the ASO's request for ‘hue minimization, the ASDS SOM was 
reassessed. The previously modeled 11 semantic objects were condensed to include only the 
objects AIRCRAFT RIDER, FLIGHTCREW and PASSENGER. The condensed ASDS 
relational model is depicted in Appendix C. 

1. ASDS Design 

Logical database design centers around the parent-subtype relationship between 
AIRCRAFT RIDER, FLIGHTCREW and PASSENGER. The parent, AIRCRAFT RIDER, 
includes two mutually exclusive subtypes, FLIGHTCREW and PASSENGER. The key of 
AIRCRAFT RIDER i SSN, the AIRCRAFT RIDER's Social Security Number. Because of 
the parent-subtype relationship, both of the subtypes are assigned the parent's key. The bar 
across the relationship lines is annotated with the sabiae group's cardinality of 1.1.1. This 
value indicates that one subtype is required, that one subtype must have a value within the 
group and that, at most, ee one of the subtypes is allowed, e.g., an AIRCRAFT RIDER 
must be either a FLIGHTCREW or a PASSEN GER but not both. The ASDS data dictionary 
appears in Appendix D. 

Z. ASDS Normalization 

The cells of each table are single valued with neither repeating groups nor arrays. All 
entries in any column (attributes) are of the same kind. Each column has a unique name and . 
column order is insignificant. No two rows of a table are identical and row order is also 
insignificant. As a result, the ASDS tables meet first normal form requirements. [Ref 7: p. 


133] 


2] 











A relation is in second normal form if all its nonkey attributes are dependent on all of 
the key [Ref: 7: p. 134]. None of the ASDS relations have composite keys. Because all three 
ASDS relations have a single attribute (SSN) as their key, the ASDS tables are in second 
normal form. 

Transitive dependencies arise if an arrangement of inebeaas dependencies exist which 
allow one attribute to determine another through a third attribute. A relation is in third 
normal form if it is in second normal form and has no transitive dependencies [Ref. 7: p. 135]. 
Each of the ASDS relations were checked for transitive dependencies. Since none were 
discovered, the ASDS tables are in third normal form. 

A relation is in fourth normal form if it has no multivalued dependencies. A 
multivalued dependency exists when a relation has at least three attributes, two of them are 
multivalued and their values depend only on the third attribute. [Ref. 7: p. 137] No multiple 
values are allowed in the ASDS attribute entries, therefor the ASDS tables are in fourth 
normal form. 

3. ASDS Menus and Forms 

The ASDS menus and forms are depicted in Appendix E by Figures 1 through 10. 
Figure 1 is the main menu which allows the user to easily navigate each of the submenus. 
Figure 2 is the NATOPS Jacket Management Program menu which allows the user to add, 
update and delete any flightcrew's NATOPS records. Options also exist for sorting and 
packing the database. Figure 3 depicts the form which allows the user to enter the 
flightcrew's name or social security number. Either entry allows the dBASE search function 


to locate the desired record. Figure 4 is the form which allows entry of each individual's 
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personal and NATOPS-related data. Figure 5 represents the Backseat Rider Program menu. 
This menu allows the user to add, update and delete backseat rider records as well as sort and 
pack the database. Figure 6 depicts the form which allows the user to enter the backseat 
rider's name or social security number. As before, either entry allows the dBASE search 
function to locate the desired record. Figure 7 is the form which allows entry of each 
backseat rider's personal and NATOPS-related data. Figure 8 represents the Safety Office — 
Report Generator menu. This menu allows the user to print the NATOPS Qualification 
Expiration and Backseat Rider Lists. In addition, the user may print a frtnatied listing of the 
entire database. Figure 9 represents the form which allows entry of the dates and report 
signer's information associated with each NATOPS Qualification Expiration List. Figure 10 
depicts the Database Backup Program menu which allows the user to backup all ASDS files. 
4. ASDS Reports 
Examples of the two reports automatically generated by the ASDS are located in 
Appendix F. These reports, titled the AERONAUTICALLY/NON-AERONAUTICALLY 
DESIGNATED BACKSEAT RIDER LIST and NATOPS QUAL EXPIRATION LIST, are 
disseminated to all squadron departments as well as the Ready Room. 
a. Backseat Rider List 
This "Backseat Rider" report includes two distinct sections. The initial section 
identifies aeronautically designated backseat riders and includes Flight Surgeons, Flight 
Physiologists and other designated aviatordNE Os from other NAS Lemoore commands as 
well as designated personnel from other military installations. The second section identifies 


non-aeronautically designated backseat riders and includes all Selected Passengers. 
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Each section of the Backseat Rider List provides rules governing those flights 
for which each backseat rider is qualified. Additionally, each backseat rider's name, rank or 
rate, next expiring NATOPS qualification, qualification. expiration date and location is 
provided. This data greatly enhances the Schedules Officer's ability to preplan the daily flight 
schedule and allows the Squadron Duty Officer to verify each backseat rider's qualifications 
_ immediately prior to flight assignment. 

b. NATOPS Qualification Expiration List 

The NATOPS Qualification Expiration List can be generated for any two- 
consecutive-month period and contains three separate sections. The first section provides the 
names of those flightcrew with already-expired NATOPS qualifications. The sean section 
provides information pertaining to those NATOPS qualifications expiring in the first selected 
month. Section three provides similar data for NATOPS qualifications expiring in the 
following month. 

In each section, the name, rank, NATOPS qualification expiring and expiration 
date are provided. This list is provided to all squadron departments and is posted in the . 
Ready Room. Each flightcrew member can check the list to verify his NATOPS qualification 
status. In addition, the Schedules Officer is now able to plan NATOPS training classes or 
qualification flights up to two months in advance. Neither of these capabilities existed prior 
to ASDS implementation. 

E. PHASE V: ASDS IMPLEMENTATION 
Ashton-Tate's dBASE III Plus and Borland's dBASE for Windows were selected to 


build the ASDS. Because dBASE for Windows is backwards compatible with dBASE II | 
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Plus, the ASDS 1s able to operate on the Safety Office's 286 and 486 PCs. dBASE was well- 
suited to handle all present Safety Department DBMS requirements as well as having ample 
ability to implement additional features in the future. Utilizing the information described 
earlier, the dstabase tables were constructed. The next step in creating the ASDS was to 
ensure the referential integrity of the data and database, i.e., if data entered in the database 
key fields were changed, all the corresponding fields in the dependent tables would also 
change. | 

The minimum system hardware parameters are: a 286 IBM compatible PC for the 
operation of dBASE III Plus or a 386 IBM compatible PC for the operation of dBASE for 
Windows. The ASDS requires only one 1.44 MB 3.5" floppy disk to hold all required ASDS 
information which includes database files, indexes, program code, screens and reports. 

Forms, reports and menus were constructed using the programming danabiiy of 
dBASE. The programming language allowed for algorithms to be built for each interactive 
menu as well as the for the formatting of the computer-generated reports related to NATOPS 
qualifications. Data input and retrieval screens were constructed utilizing dBASE's screen 
builder. The ASDS dBASE source code appears in Appendix G. 

The parallel strategy of database implementation was selected by the ASO. This 
strategy was viewed as optimum because no one in the Safety Department had previously 
operated a database system. The NATOPS Officer and ASPO were concerned that a future 

failure of the ASDS combined with a failure to maintain the long-used manual NATOPS 
qualification ae system ceil decrease rather than increase overall Safety Department 


efficiency. This implementation strategy is safest because it allows both systems to be utilized 
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simultaneously. Should any difficulties arise with the ASDS, no deleterious effects would be 
suffered by the Safety Department. A drawback is the small increase of man-hours spent in 
the “double entry" of data into the two systems. 

Familiarization and training sessions were conducted with the NATOPS Officer, 
ASPO and Safety Office staff to enable them to become comfortable with the database 
system's sivainees: intricacies and capabilities. Because the ASDS is both interactive and user- 
friendly, extensive training was not required. Safety Office staff quickly learned to navigate 
through the ASDS's simple push-button screens and menus. As the ASDS maintainer, the 
ASPO received additional training in program reinstallation, back-up techniques and 
| troubleshooting options. 

ASDS testing consisted of entering all data related to every squadron IP, RP and 
Selected Passenger into the database. The intent was to seen whether the ASDS could 
provide reports identifying who was out of qualification and what those = were. 
Immediately prior to generating the ASDS reports, a thorough screening of every NATOPS 
Jacket was conducted. The ultimate test of the ASDS was to check the computer generated 
reports against the manual screening results for discrepancies. No sors were found. Minor 
modifications wae aisle to the system to correct menu, screen and report formatting errors 
when any were detected. 

ASDS maintenance will arianl be provided by the system administrator (the ASPO) 
who will perform daily back-ups, system reloads and data integrity checks. Revisions to the 


dBASE source code will be performed by the author. In the future, Safety Department 
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personnel may wish to add additional capabilities to the ASDS. In this case, a study of the 


dBASE programming language and algorithm construction would be required. 
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IV. CONCLUSIONS 


The ASDS has been on-line for many months and continues to successfully meet the 
expectations of the users in that the ASDS performs every function initially envisioned by the 
ASO. The Safety Department staff have a to rely heavily on the computer-generated 
NATOPS reports. Staff members have also learned, through error recognition, that the input 
of data to the ASDS is the most important part of overall system integrity. If a data entry 
error is made, future NATOPS qualification expiration reports will eventually contain 


erroneous information. As a result, data entry clerks make a concerted effort to be error free. 


Both Safety and Operations Department personnel have already realized an immense increase 


in overall efficiency - especially in the ability to plan ahead. 

Database design is an iterative process aveine the constant reeducation of both the 
database designer as well as the ultimate user. As in the case of VFA-125's ASO and Safety 
Office staff, many users have little or no previous database experience and, as a result, ae 
unaware of either the customer needs analysis process or DBMS design methodology. 
Through an in-depth study of the ASDS entity-relationship model, the SOM and finally the 
relational model, the ASO was able to narrow the scope of the ASDS project. This 


evolutionary process resulted in a final ASDS product vastly different from the DBMS 


initially envisioned by the database designer. Most importantly though, this process 


successfully resulted in a final product meeting each of the users' specific needs. _ 


It is important to recognize that the Navy has many large aviation squadrons with 


_ large numbers of assigned aircrew. These same squadrons may also provide services to 
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selected passengers. Currently no standardized Navy-wide automated NATOPS qualification 
database tracking system is available. Those NATOPS qualification DBMSs that do exist are 
individually constructed and, like the VFA-125 ASDS, specifically tailored to an individual 
aviation squadron's needs. No system compatibility exists between these stand-alone DBMS&s. 
In those large aviation squadrons that continue to track the numerous NATOPS qualifications 
manually, the probability significantly increases iil aircrew and/or passengers fly without | 
being fully NATOPS qualified. Oftentimes, this fact is only uncovered during mishap 
investigations. It is imperative, especially during this period of military downsizing, that the 
oo intensive manual NATOPS qualification tracking system be replaced by an 
automated NATOPS DBMS. The benefits are clear - increased efficiency and greater overall 
safety. 

Three recommendations result from this study: 

@ A single, standard IBM PC Windows-based database application be sloiel by the 
| Navy and provided to each aviation squadron. 

@ The Naval Safety Center should design and build a standardized NATOPS 
qualification tracking database system utilizing the aparaved database application. This 
NATOPS DBMS would be sroviica to each aviation squadron. 

@ The Naval Safety Center would act as the DBMS's central custodian or "model 
manager" responsible for soliciting, collecting, effecting and disseminating changes to the 
DBMS. This would continue to ensure that every aici had the same NATOPS DBMS 
with the latest updates. It would also guarantee each squadron a single conduit for 


recommended DBMS revisions. 
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By these actions, the Naval Safety Center could greatly reduce the possibility of future 


pilot-error aviation mishaps while simultaneously standardizing the NATOPS qualification 





tracking system throughout the Navy. 
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APPENDIX A: ASDS ENTITY-RELATIONSHIP MODEL 
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NATOPS 
EVALUATION 





36 MONTH. 
WATER 
SURVIVAL 


_ CLASS 


Ke 
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ES 






ANNUAL 
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APPENDIX B. ASDS SEMANTIC OBJECT MODEL 





AIRCRAFT RIDER 


‘ID SSN 
Name 
RankRate 


Grade 
Service 
Designator 
BirthDate 
BurthMonth 














| EGRESS 
ID SSN 


Name 
RankRate 


TypeSeat 


InstructionDate 
Grade 
Unit 


Instructor 














~ PHYSICAL 
_ ID SSN 


Name 

RankRate 

Service 
PhysicalDate 
PhysicalExpiration 











PAS: SENGER. 


Location 
Billet 
PhoneNumber 








‘SWIM 
ID SSN 


Name 
RankRate 
Category 
InstructionDate 
Grade 

Unit 

Instructor 





MANUALS 
- ID ManualID j 


ManualT ype 
ManualNumbe 


41 


1D SSN | 


PHYSIOLOGY 
ID SSN 


Name 
RankRate 
Category 


InstructionDate 
Grade 


Unit 


Instructor 


| INSTRUMENT QUAL 
_ ID SSN 


Name 

Rank 

Unit 

Rating 
DateOfCheck 
ExpirationDate 
Examiner | 
Issuer 





Name 
Rank 
Squadron 
AircraftModel 
CrewPosition 
FlightHours 
Evaluator 
DateOfEval 











1D ClassNumber 


StartDate 
PhaseDates 


NumberStudents 
GraduationDate 
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APPENDIX C. ASDS RELATIONAL MODEL 


AIRCRAFT RIDER 





PASSENGER 


[ss | ofice | rset | rae | AmoDesionae 


PASSENGER (Continued 


aa |e [om 





sev] designe | | RP] Gass | tack | riawators 


_ FLIGHTCREW (Continued 


T34NATOPS | FAI8PCL | FAISNATMan | FA18Pef | FAI8TacPCL 


FLIGHTCREW Cann 
eeu alee ae cai 
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APPENDIX D. ASDS DATA DICTIONARY 


A. SEMANTIC OBJECT DEFINITIONS 


1. 


AIRCRAFT RIDER Object (Supertype) 


*SSN; Aircraft-rider social-security-number 

NAME; Aircraft-rider-name 

RANK; Aircraft-rider-rank 

SERVICE; Aircraft-rider-service 

GRADE; Aircraft-rider-grade 

BIRTHDATE; Aircraft-rider-date-of-birth 
BIRTHMONTH; Aircraft-rider-birth-month 

UPCHIT; Aircraft-rider-medical-up-chit-expiration-date 
F18SEAT; Aircraft-rider-F/A-18-seat-expiration-date 
T34EGRESS; Aireeafi-rider-T-34-egress-expiration-date 
SWIM; Aircraft-tider-swim-expiration-date 


PHYSIOLOGY; Aircraft-rider-physiology-expiration-date 


FLIGHTCREW Object (Subtype Object of AIRCRAFT RIDER) 


*SSN; Aircraft-rider-social-security-number (Supertype's key) 
DESIGNATOR; Flightcrew-designator 


IP; Flightcrew-instructor-pilot-status 


4S 





RP; Flightcrew-replacement-pilot-status 

CLASS; Flightcrew-class-assignment 

INSTCHECK; Flightcrew-instrument-check-expiration-date 
FI8NATOPS; Flightcrew-F/A-1 8-NATOP S-check-expiration-date 
T34QUAL; Flightcrew-T-34-qualification-status 

T34NATOPS; Flightcrew-T-34-NATOPS-check-expiration-date 
FAI8PCL, Flightcrew-F/A-18-pocket-checklist-number 
FAI8NATMAN; Flightcrew-F/A-1 8-NATOPS-manual-number | 
FA18PERF; Flightcrew-F/A-18-performance-charts-number 
FAI8TACPCL; Flightcrew-F/A-18-tactical-pocket-checklist-number 
FA18EPEPCL; Flightcrew-F/A-18-EPE-pocket-checklist-number 
T3 4PCL; Flightcrew-T-34-pocket-checklist-number 
T34NATMAN; Flightcrew-T-3 4-NATOP S-manual-number 
IFRMAN; Flightcrew-in-flight-refueling-manual-number 
OPNAV3710; Flightcrew-OPNAV-3 710-number 


CVNATOPS; Flightcrew-CV-NATOPS-manual-number 


PASSENGER Object (Subtype of AIRCRAFT RIDER) 
@ *SSN; Aircraft-rider-social-security-number (Supertype's key) 
e OFFICER: Passenger-officer-status 


@ ENLISTED; Passenger-enlisted-status 
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@ RATE; Passenger-enlisted-rate 


AERODESIG; Passenger-aerodesignation-status 


LOCATION; Passenger-work-location 
® BILLET: Passenger-billet 


@ PHONE; Passenger-phone-number | 


OUTOFQUAL; Passenger-NATOPS-qualification-status 


DOMAIN DEFIN ITIONS 
@ Social-security-number 
| ¢ Numeric 9 

¢ Social security number of aircraft rider 
e AGrcpahtidersname 

+ Character 20 

¢ Last name, first initial and middle initial of aircraft rider 
e Aircratt-rider-rank 

¢ Character 5 

¢ Rank of officer aircraft rider, standard military abbreviation 
@ Aircraft-rider-service oe 

° Character 5 


¢ Military service branch of aircraft rider 
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Aircraft-rider-grade 

¢ Numeric 1 

* Military grade of aircraft rider 
Arrcraft-rider-birthdate 

+ Date 8, Mask MM/DD/YYYY 

¢ Date of aircraft rider's birth 
Aircraft-rider-birthmonth 

¢ Character 3 

¢ Month of aircraft rider's birth 
Aircraft-rider-upchit 

« Date 8, Mask MM/DD/YYYY 

¢ Expiration of aircraft nder's alia upchit 
Aircraft-rider-F/A-18-seat | 

¢ Date 8, Mask MM/DD/YY YY 

7 Expiration of aircraft rider's F/A-18 seat qualification 
Aircraft-rider-T-34-egress 

¢ Date 8, Mask MM/DD/YYYY 

¢ Expiration date of aircraft rider's T-34 aircraft egress qualification 
Aircrafi-rider-swim 

¢ Date 8, Mask MM/DD/YYYY 


¢ Expiration date of aircraft rider's swim training qualification 
p : £q 
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Aircraft-rider-physiology 

¢ Date 8, Mask MM/DD/YY YY 

* Expiration date of aircraft rider's flight physiology training qualification 
Flightcrew-designator 

¢ Numeric 4 

¢ Flightcrew designator 
Flightcrew-instructor-pilot 

¢ Logical 1 

¢ Flightcrew instructor pilot status 
Flightcrew-replacement-pilot 

¢ Logical 1 

. hlighicrew replacement pilot status 
Piohicreweiads 

¢ Numeric 4 

¢ Flightcrew ceplacenicat pilot class assignment number 
Flightcrew-instrument-check 

"Baas 8, Mask MM/DDIYYYY 

¢ Flightcrew instrument check expiration date 
Flightcrew-F/A-18-NATOPS-check 

¢ Date 8, Mask MM/DD/YYYY 


os Flightcrew NATOPS check expiration date 
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Flightcrew-T-34-qualification-status 

¢ Logical 1 

. Flightcrew status regarding T-34 qualification 
Flightcrew-T-34-NATOPS-check 

¢ Date 8, Mask MM/DD/YYYY 

¢ Flightcrew T-34 NATOPS qualification expiration date 
Flightcrew-F/A-1 8-pocket-checkli st 

i Shancali 3 

¢ Flightcrew F/A-18 NATOPS pocket checklist number 
Flightcrew-F/A-18-NATOPS-manual _ 

¢ Numeric 3 

¢ Flightcrew F/A-18 NATOPS manual number 
Flightcrew-F/A-18-p erformance-manual 

: Numeric 3 ~ 

¢ Flightcrew F/A-18 NATOPS performance manual number 
Flightcrew-F/A-18-tactical-pocket-checklist 

¢ Numeric 3 

¢ Flightcrew F/A-18 NATOPS tactical pocket checklist number 
ee ee ee ee ee ae a 

¢ Numeric 3 


¢ Flightcrew F/A-18 NATOPS enhanced performance engine PCL number 
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Flightcrew-T-34-pocket-checklist 

¢ Numeric 3 

¢ Flightcrew T-34 NATOPS pocket checklist number 
Flightcrew-T-34-NATOPS-manual 

¢ Numeric 3 

¢ Flightcrew T-34 NATOPS pocket checklist number 
Flightcrew-in-flight-refueling-manual 

¢ Numeric 3 

¢ Flightcrew NATOPS in-flight cations manual number 
Flightcrew-OPNAV-3710-manual 

¢ Numeric 3 

¢ Flightcrew OPNAV 3710.7 series NATOPS manual numiber 
Flightcrew-CV-NATOPS-manual 

¢ Numeric 3 

¢ Flightcrew CV NATOPS manual number 
‘eeieaisictliceiiti 

— © Logical 1 

¢ Passenger officer status 
_Passenger-enlisted-status 
¢ Logical 1 


* Passenger enlisted status 
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2 Passenger-rate 

¢ Character 5 

* Passenger enlisted military rate 
@ Passenger-aerodesignation-status 

¢ Logical 1 

¢ Passenger aerodesignation status 
@ Passenger-location 

¢ Character 15 

* Passenger contact location 
@ Passenger-billet 

¢ Character 10 

¢ Passenger military or civilian position 
@ Passenger-phone 

¢ Character 15 

¢ Passenger contact phone number 


Passenger-qualification-status 


¢ Logical 1 


¢ Passenger NATOPS qualification status 


a2 





APPENDIX E. ASDS MENUS AND FORMS 


VFA-125 NATOPS PROGRAM MANAGER 


. NATOPS JACKET MANAGEMENT PROGRAM 
. BACK SEAT RIDER PROGRAM 
. PRINT REPORTS 


. BACK UP DATABASE FILES 
. EXIT MENU TO ASSIST SCREEN 
. EXIT MENU TO DOS PROMPT 


PLEASE MAKE YOUR SELECTION :22:: 


Figure 1. ASDS Main Menu 


_ NATOPS JACKET MANAGEMENT PROGRAM 


. ADD NEW NATOPS JACKETS 

_ UPDATE EXISTING NATOPS JACKETS 
. DELETE OLD NATOPS JACKETS: 
. SORT NATOPS DATABASE 

. PACK NATOPS DATABASE 

_ RETURN TO MAIN MENU 


PLEASE MAKE YOUR SELECTION : 





Figure 2. ASDS NATOPS Jacket Management Program Menu 
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ENTER NAME OR SOCIAL SECURITY NUMBER OF AVIATOR TO BE UPDATED 


ENTER LAST NAME, FI. MI. OF aia 


-OR - 


ENTER SOCIAL SECURITY NUMBER OF AVIATOR TO BE UPDATED 


Figure 3. NATOPS Jacket Search Form 


VFA-125 ROUGH RAIDER NATOPS DATA FORM 

LAST NAME, FI. MI. : Q aes 
DESIGNATOR) Be CLASS :. ot 

BIRTHDAY :). BIRTHMONTH: 2: T-34 nore 


WATER SURVIVAL EXPIRATION DATE #28: 
PHY SIOLOGY/CHAMBER EXPIRATION DA 
INSTRUMENT CHECK EXPIRATION DATE : 


ANNUAL FLIGHT PHYSICAL EXPIRATION DATE 
F/A-18 NATOPS QUAL EXPIRATION DATE : 
F/A-18 SEAT QUAL EXPIRATION DATE :. 

T-34 NATOPS QUAL EXPIRATION DATE : 

T-34 EGRESS QUAL EXPIRATION DATE : 


F/A-18 NATOPS MAN :: ea : TAC PCL :. ue aN 3710: 
F/A-18 PERFORMANCE } MAN # : T-34 NATOPS -Cy NATOPS : 
F/A-18 POCKET CHECKLIST : :T- 34 PCL: : 





Figure 4. NATOPS Jacket Data Entry Form 
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VFA-125 BACKSEAT RIDER PROGRAM 


. ADD NEW BACKSEAT RIDER 

. UPDATE EXISTING BACKSEAT RIDER 

. DELTE EXPIRED BACKSEAT RIDER 
SORT BACKSEAT RIDER DATABASE 

. PACK BACKSEAT RIDER DATABASE 

. RETURN TO MAIN MENU 


PLEASE MAKE YOUR SELECTION : 





Figure 5. Backseat Rider Program Menu 


ENTER NAME OR SSN OF BACKSEAT RIDER TO BE UPDATED 


ENTER LAST NAME, FI. MI. OF BACKSEAT RIDER 





: Figure 6. Backseat Rider Search Form 
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LAST NAME, FL ML : pee 
OFFICER :): RANK # ©: GRADE::: ENLISTED :!: RATE: : SERVICE: 


BIRTHDATE : @* : BIRTH MONTH: ®% : AERODESIGNATED : ®: 
LOCATION =" 


ANNUAL PHYSICAL EXPIRATION DATE : 

F/A-18 EJECTION SEAT EXPIRATION DATE : : 

T-34 EGRESS/BAILOUT EXPIRATIONDATE: = _: 
| IS THIS PERSON OUT OF QUAL? : ic 





Figure 7. Backseat Rider Data Entry Form 


SAFETY OFFICE REPORT GENERATOR 


~ PRINT NATOPS QUAL LIST 
_ PRINT NATOPS DATABASE 
. PRINT BACK SEAT LIST 

_ RETURN TO MAIN MENU 


PLEASE MAKE YOUR SELECTION : ...; : 





Figure 8. Safety Office Report Generator Menu 
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ENTER ENDING DATE OF PREVIOUS MONTH: |: 
ENTER ENDING DATE OF PRESENT MONTH 
ENTER ENDING DATE OF NEXT MONTH: | |: 
ENTER NAME OF REPORT SIGNER: _ : 

ENTER RANK OF REPORT SIGNER : 


ENTER SERVICE OF REPORT SIGNER: . : 


ENSURE THE PRINTER IS ON AND PAPER LOADED 





Figure 9. NATOPS Report Entry Form 





DATABASE BACKUP PROGRAM | : 


PLACE THE SAFETY/NATOPS DATABASE DISK IN DRIVE A: 





CONTINUE WITH DATABASE BACKUP? (Y/N) :i 


COPYING NATOPS.DBF COPYING BACKSEAT.DBF 
COPYING NAMEINDX.NDX COPYING NAMEBACK.NDX 
COPYING SSNINDEX.NDX COPYING SSNBACK.NDX 


COPYING UTILITY.DBF 


BACKUP COMPLETE. PRESS ANY KEY TO CONTINUE 


Figure 10. NATOPS Database Backup Program Menu 
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APPENDIX F. ASDS NATOPS REPORTS 


15 APR 96 


MEMORANDUM 


From: Aviation Safety Officer, Strike Fighter squadron ONE TWO FIVE 
To: Operations Officer, Strike Fighter Squadron ONE TWO FIVE 
Info: _CDO/ODO/SDO/Schedules Officer 


Subj: AERONAUTICALLY/NON-AERONAUTICALLY DESIGNATED BACKSEAT 
RIDER LIST 


Ref: (a) VFA-125INST 3710.4D 
(b) OPNAVINST 3710.7Q 


1. As outlined 1n reference (a), the listed aeronautically designated personnel may 
occupy the aft seat of VFA-125 aircraft with the following restrictions: 


A. Only qualified IPs will be selected to conduct backseat rider proficiency and 
incentive flights. | 
B. No backseat riders in PMCF or in-flight refueling flights: 
C. Aeronautically designated personnel may fly in the aft cockpit of the following 
flights: 
(1) All Transition Phase flights (FORM, NAV, AWI) and VIDs. 
(2) BFM and LAT flights with the IP’s approval. 
(3) FWT and STRIKE sorties with Phase Head authorization. | 
(4) CV flights with CO’s or OPS Officer approval. 
(5S) GUN Stage flights. 


| ey The following personnel are AERONAUTICALLY DESIGNATED Backseat Riders 
in accordance with reference (b): 


RANK/ QUAL | QUAL RIDER 
NAME | RATE EXPIRING EXPDATE LOCATION 
BRANSDORFER, A.H. LT - UPCHIT 01/31/97 APTU 
MILLIGAN, L. A. LT UPCHIT 10/31/96 APTU 
THORNTON, J.F. = ~~ LT UPCHIT 02/28/97 VMFA-212 
ANTICLIFFE, S. J. 1STLT  FI8SEAT 11/30/96 MATSG 
~ DAHL, W. A. LTJG UPCHIT 09/30/96 CSFWP 
GILBERT, M. AO2 UPCHIT 02/28/97 OMD 


STREIB, R. F. AMSC FI8SEAT 08/31/96 NASL OPS 
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3. As outlined in reference (a), the listed non-aeronautically designated personnel may 
occupy the aft seat of VFA-125 aircraft with the following restrictions: 


A. Only qualified IPs will be selected to conduct backseat rider proficiency and 
incentive flights. 

B. No backseat riders in PMCF or in-flight refueling flights. | 

C. Flights are limited to Transition Phase (FORM, NAV, AWI) and VID. 

D. Non-aeronautically designated personnel may not fly in the aft cockpit of the 
following flights: 
(1) Night flights. 
(2) Flights when the field is IFR. 
(3) Flights to or from the CV. 
(4) Flights that do not begin and end at the same field. 


4. The following personnel are NON-AERONAUTICALLY DESIGNATED Backseat 
riders in accordance with reference (b). 


RANK/ QUAL - QUAL RIDER» 
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NAME RATE EXPIRING EXP DATE LOCATION 
BOSWELL, B. LCDR UPCHIT | 01/19/97 ALAMEDA 
KELLY, J. G. LT FI8SEAT 02/28/97  APTU 
FERREL, M. D. LTJG FI8SEAT 12/31/96  V¥FA-125 
LUCAS, E. C. LTJG UPCHIT 01/30/97 VFA-113 
BALCH, T. A. ENS F18SEAT 02/28/97 | SFWSP 
' GATES, J. H. ENS SWIM 06/30/96 | SFWSP 

ALBERT, D. M. AT3 F18SEAT 11/30/96 VFA-303 
‘ANDERSON, V. SGT UPCHIT - 03/11/97 NAMTRA 
ASAKEVICH, D. J. LCPL UPCHIT 01/13/97  W/C13B 
DARCY, J. T. AC3 FI8SEAT | 11/30/96 | NASL OPS 
DAVIS, G. P. AKAN F18SEAT 11/30/96 VAQ-34° 
HECHEL, R. AE3 UPCHIT 03/18/97 AESHOP 
JACKSON, W. LCPL F18SEAT 11/30/96 MATSG 

T. R. MARTIN 

LCDR USN 








15 APR 96 


MEMORANDUM 

From: Aviation Safety Officer, Strike Fighter squadron ONE TWO FIVE 
To: — All Squadron Flightcrew , 

Via: Operations Officer, Strike Fighter Squadron ONE TWO FIVE 
Subj: NATOPS QUAL EXPIRATION DATES FOR APRIL/MAY 

Ref: (a) OPNAVINST 3710.7Q 


1. As per reference (a), the following qualifications have expired: 


Name Rank _ Qual Date 
GRAFFIS.KH = LCDR UPCHIT i (sti 03/31/96 
WEINMANN,D.S.  ——sSOXASTLT | UPCHIT 02/29/96 
JOHNSON.M. A. ~ LTJG INSTCHECK 03/31/96 
SOBYRA, M. R. MAJ ) ”: FLISNATOPS 03/31/96 
GALLAGHER, S. R. LT PHYSIOLOGY 02/29/96 
GALLAGHER, S. R. LT SWIM | 02/29/96 
SHAW, G. P. MAJ FISSEAT | 03/31/96 
GRAHAM, M. E. LT FI8SEAT 03/31/96 
COWART, J. W. LT T34NATOPS  —s=—_=s 03/31/96 
COWART, J. W. LT _-—- T34EGRESS 03/31/96 


Name Rank Qual Date 
ARNOTT, R. E.. CAPT | UPCHIT “04/30/96 
BALL, G E. LT UPCHIT 04/30/96 


CONSOLE, K. M.. ISTLT | UPCHIT. - 04/30/96 
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HIMEL, C.A. 
MCKENZIE, G: S. 


ELIOT, G. M. 
MAKRIDIS B. K. 


KENNEDY, R. J. 
GORTHY, A. R. 


WRIGHT, C. R. 
WINDER, R. P. 


A a ah Ye FS DD eagle ay ey a gy ee re ehh tht i pinoy aly SSE NS ems ale heel 


05/31/96 


_ BREWER, T. G. 


STEFANSIC, S. P. 


DWYER, D. W. 


BERGMAN, D. M. 


_ CUESTA, J.M. 


DIXON, J. R. 
NELMS, R. M. 


MONSON, A. P. 


MONSON, A. P. 





CDR 
FLTLT 


LTCOL 


LCDR 
CAPT 
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INSTCHECK 
INSTCHECK 


FI8NATOPS 
F18NATOPS 


PHYSIOLOGY 
SWIM 


F18SEAT 
Fi8SEAT 


T34NATOPS 


T34NATOPS 


INSTCHECK 
INSTCHECK 


FI8NATOPS 


FI8SEAT 
F1I8SEAT © 


T34NATOPS 


T34EGRESS 


04/30/96 


04/30/96 


04/30/96 


04/30/96 ... 


04/30/96 
04/30/96 


04/30/96 
04/30/96 


04/30/96 


04/30/96 


05/31/96 


05/31/96 
05/31/96 


05/31/96 


05/31/96 
05/31/96 


— 05/31/96 


- 05/31/96 





APPENDIX G. ASDS DBASE SOURCE CODE 


* SAFETY.PRG 
CLEAR ALL 
DO WHILE .T. 
CLEAR 
@ 2,0 TO 20,79 DOUBLE 
@ 3,22 SAY "VFA-125 NATOPS PROGRAM MANAGER" 
@ 4,1 TO 4,78 DOUBLE 
@ 7,22 SAY "1. NATOPS JACKET MANAGEMENT PROGRAM" 
@ 8,22 SAY "2. BACK SEAT RIDER PROGRAM" 
@ 9,22 SAY "3. PRINT REPORTS" 
@ 10,22 SAY "4. BACK UP DATABASE FILES" 
@ 11,22 SAY "5. EXIT MENU TO ASSIST SCREEN" 
@ 12,22 SAY "6. EXIT MENU TO DOS PROMPT" 
@ 14,25 SAY "PLEASE MAKE YOUR SELECTION" 
STORE 0 TO SELECTION 
@ 14,52 GET SELECTION PICTURE "9" RANGE 1,6 
READ 
DO CASE 
CASE SELECTION=1 
DO JACKETS 
CASE SELECTION=2 
DO BACKSEAT 
CASE SELECTION=3 
DO REPORTS 
CASE SELECTION=4 
STORE "Y" TO backitup 
DO BACKUPS 
CASE SELECTION=5 
~ STORE "" TO backitup 
DO BACKUPS 
CLOSE PROCEDURE 
CLEAR ALL 
ASSIST 
EXIT 
CASE SELECTION=6 
STORE "" TO backitup 
DO BACKUPS 
QUIT 
ENDCASE SELECTION 
ENDDO 
* 


* 


PROCEDURE JACKETS 
DO WHILE.T. 
CLEAR 
-@2,0 TO 20,79 DOUBLE 
@ 3,23 SAY "NATOPS JACKET MANAGEMENT PROGRAM" 
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@ 4,1 TO 4,78 DOUBLE 
@ 8,23 SAY "1. ADD NEW NATOPS JACKETS" 
@ 9,23 SAY "2. UPDATE EXISTING NATOPS JACKETS" 
@ 10,23 SAY "3. DELETE OLD NATOPS JACKETS" 
@ 11,23 SAY "4. SORT NATOPS DATABASE" 
@ 12,23 SAY "5. PACK NATOPS DATABASE" 
@ 13,23 SAY "6. RETURN TO MAIN MENU" 
@ 15,26 SAY "PLEASE MAKE YOUR SELECTION" 
STORE 0 TO SELECTION 
@ 15,53 GET SELECTION PICTURE "9" RANGE 1,6 
READ 
DO CASE 
CASE SELECTION=1 
DO ADDPILOT 
CASE SELECTION=2 
DO UPDATES 
CASE SELECTION=3 
DO DELETES 
CASE SELECTION=4 
STORE "sortit" TO CHOICE 
DO SORTPACK 
CASE SELECTION=5 
STORE "packit" TO CHOICE 
‘DO SORTPACK 
CASE SELECTION=6 
CLEAR 
RETURN | 
-ENDCASE SELECTION 
ENDDO a 


* 
* 


PROCEDURE ADDPILOT 

USE C:\DBASE\NATOPS\NATOPS 

CLEAR 

STORE 999999999 TO ssntemp 

STORE SPACE(20) TO nametemp 

@ 2,0 TO 20,79 DOUBLE 

@ 6,15 SAY "ENTER NAME OR SOCIAL SECURITY NUMBER OF NEW AVIATOR" 
@ 8,23 SAY "ENTER LAST NAME, FI. MI. OF AVIATOR" 


@ 1 36 SAY "- OR -" 
@ 13,18 SAY "ENTER SOCIAL SECURITY NUMBER OF NEW AVIATOR" - 
@ 14,33 GET ssntemp PICTURE "@R #-###-##4#" 
READ 
IF nametemp<>SPACE(20) 
SET INDEX TO C:\DBASE\NATOPS\NAMEINDX,C:ADBASE\NATOPS\SSNINDEX 
GO TOP 
SEEK TRIM(nametemp) 
IF NAME=TRIM(nametemp) 
SET COLOR TO R+/B,R/W,BR 
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@ 16,20 SAY "THIS AVIATOR IS ALREADY IN THE DATABASE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT "" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
ENDIF 
IF ssntemp<>999999999 | 
SET INDEX TO C:\DBASE\NATOPS\SSNINDEX,C:\DBASE\NATOPS\NAMEINDX 
GO TOP 
SEEK ssntemp 
IF ssntemp=SSN 
SET COLOR TO R+/B,R/W,BR 
@ 16,20 SAY "THIS AVIATOR IS ALREADY IN THE DATABASE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT "™" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
ENDIF | 
IF (ssntemp=999999999 .AND. nametemp=SPACE(20)) 
SET COLOR TO R+/B,R/W,BR 
@ 16,31 SAY "NO ENTRY WAS MADE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT "" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
SET FORMAT TO C:\DBASE\NATOPS\NATOPS | 
SET MESSAGE TO "WHEN NEW RECORD ENTRIES ARE COMPLETE PRESS CTRL-END" 
- APPEND 
SET MESSAGE TO "" 
CLOSE DATABASES 
CLEAR | 
RETURN 
* 
* 
PROCEDURE UPDATES 
USE C:\DBASE\NATOPS\NATOPS 
CLEAR -- 
STORE 999999999 TO ssntemp 
STORE SPACE(20) TO nametemp 
@ 2,0 TO 20,79 DOUBLE 
@ 6,10 SAY "ENTER NAME OR SOCIAL SECURITY NUMBER OF AVIATOR TO BE UPDATED" 
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@ 8,23 SAY "ENTER LAST NAME, FI. MI. OF AVIATOR" 


@ 7 36 SAY "- OR -" 
@ 13,14 SAY "ENTER SOCIAL SECURITY NUMBER OF AVIATOR TO BE UPDATED" 
@ 14,33 GET ssntemp PICTURE "@R ###-##-##4##" 
READ 
IF nametemp<>SPACE(20) 
SET INDEX TO C:\DBASE\NATOPS\NAMEINDX.C: \DBASE\NATOPS\SSNINDEX 
GO TOP 
SEEK TRIM(nametemp) 
IF EOFO 
SET COLOR TO R+/B,R/W,BR 
@ 16,18 SAY "THIS AVIATOR DOES NOT EXIST IN THE DATABASE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT ™ 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
ENDIF 
IF ssntemp<>999999999 
SET INDEX TO C:\DBASE\NATOPS\SSNINDEX,C:\DBASE\NATOPS\NAMEINDX 
GO TOP 
SEEK ssntemp 
IF ROFQ 
SET COLOR TO R+/B,R/W,BR 
@ 16,18 SAY "THIS AVIATOR DOES NOT EXIST IN THE DATABASE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
ENDIF 
IF (ssntemp=999999999 AND. nametemp=SPACE(20)) _. 
SET COLOR TO R+/B,R/W,BR 
@ 16,31 SAY "NO ENTRY WAS MADE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENO" 
SET COLOR TO W+/B,R/W,BR 
WAIT" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
SET FORMAT TO C:\DBASE\NATOPS\NATOPS 
SET MESSAGE TO "WHEN.UPDATED RECORD ENTRIES ARE COMPLETE PRESS CTRL-END" 
EDIT RECNOO 
SET MESSAGE TO "" 
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CLOSE DATABASES 
CLEAR; 
RETURN 


* 
* 


PROCEDURE DELETES 

USE C’\DBASE\NATOPS\NATOPS 

CLEAR 

STORE 999999999 TO ssntemp 

STORE SPACE(20) TO nametemp 

@ 2,0 TO 20,79 DOUBLE 

@ 6,10 SAY "ENTER NAME OR SOCIAL SECURITY NUMBER OF AVIATOR TO BE DELETED" 
@ 8,23 SAY "ENTER LAST NAME, FI. MI. OF AVIATOR" 


@ 11 36 SAY "- OR -" 
@ 13,14 SAY "ENTER SOCIAL SECURITY NUMBER OF AVIATOR TO BE DELETED" 
@ 14,33 GET ssntemp PICTURE "@R ###-#4-##4#" 
READ 
IF nametemp<>SPACE(20) 
SET INDEX TO C:\DBASE\NATOPS\NAMEINDX,C:\DBASE\NATOPS\SSNINDEX 
GO TOP | 
SEEK TRIM(nametemp) 
IF EOFQ 
SET COLOR TO R+/B,R/W,BR 
@ 16,18 SAY "THIS AVIATOR DOES NOT EXIST IN THE DATABASE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT "" | 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
ENDIF 
IF ssntemp<>999999999 
SET INDEX TO C\DBASE\NATOPS\SSNINDEX,C:\DBASE\NATOPS\NAMEINDX 
GO TOP | 
SEEK ssntemp 
IF EOFO 
SET COLOR TO R+/B,R/W,BR 
@ 16,18 SAY "THIS AVIATOR DOES NOT EXIST IN THE DATABASE" 
@ 17,11 SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF — - 
ENDIF 
IF (ssntemp=999999999 AND. seas aa aes 
SET COLOR TO R+/B,R/W,BR 
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@ 16,31 SAY "NO ENTRY WAS MADE" 
@ 17,1] SAY "PRESS ANY KEY TO RETURN TO THE NATOPS JACKET TRACKING MENU" 
SET COLOR TO W+/B,R/W,BR 
WAIT "" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
SET FORMAT TO C:\DBASE\NATOPS\NATOPS 
SET MESSAGE TO "TO DELETE PRESS CTRL-U, THEN CTRL-END. TO EXIT PRESS CTRL-END" 
EDIT RECNO() 
SET MESSAGE TO "" 
CLOSE DATABASES 
CLEAR 
RETURN 
* 
* 


PROCEDURE SORTPACK 
DO CASE 
CASE CHOICE="sortit" 
SET COLOR TO R+/B,R/W,RB 
@ 17,25 SAY "SORTING NATOPS QUAL DATABASE" 
SET COLOR TO W+/B,R/W,RB 
USE CADBASE\NATOPS\NATOPS 
SORT ON NAME TO CADBASE\NATOPS\TEMPDB 
CLOSE DATABASES 
DELETE FILE C:\DBASE\NATOPS\NATOPS.DBF 
RENAME C:\DBASE\NATOPS\TEMPDB.DBF TO C:\DBASE\NATOPS\NATOPS.DBF 
USE C:\DBASE\NATOPS\NATOPS 
SET INDEX TO C:\DBASE\NATOPS\NAMEINDX,C:\DBASE\NATOPS\SSNINDEX 
@ 17,5 CLEAR TO 17,75 
SET COLOR TO R+/B,R/W,RB 
@ 17,17 SAY "SORTING COMPLETE - REINDEXING NATOPS DATABASE" 
SET COLOR TO WHB,R/W,RB 
REINDEX 
CLOSE DATABASES 
CLEAR 
RETURN 
CASE CHOICE="packit" 
SET COLOR TO R+/B,R/W,RB 
@ 17,25 SAY "PACKING NATOPS QUAL DATABASE" 
@ 18,27 SAY "TO REMOVE DELETED FILES" 
SET COLOR TO W+/B,R/W,.RB 
USE C:\DBASE\NATOPS\NATOPS 
SET INDEX TO C:\DBASE\NATOPS\NAMEINDX,C:\DBASE\NATOPS\SSNINDEX 
PACK 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDCASE CHOICE 
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* 
* 


PROCEDURE BACKSEAT 
DO WHILE.T. 
CLEAR 
@ 2,0 TO 20,79 DOUBLE 
@ 3,24 SAY "VFA-125 BACKSEAT RIDER PROGRAM" 
@ 4,1 TO 4,78 DOUBLE ate 
@ 8,23 SAY "1. ADD NEW BACKSEAT RIDER" 
@ 9,23 SAY "2. UPDATE EXISTING BACKSEAT RIDER" 
@ 10,23 SAY "3. DELETE EXPIRED BACKSEAT RIDER" 
@ 11,23 SAY "4. SORT BACKSEAT RIDER DATABASE" 
@ 12,23 SAY "5. PACK BACKSEAT RIDER DATABASE" 
@ 13,23 SAY "6. RETURN TO MAIN MENU" 
@ 15,26 SAY "PLEASE MAKE YOUR SELECTION" 
- STORE 0 TO SELECTION 
@ 15,53 GET SELECTION PICTURE "9" RANGE 1,6 
READ | 
DO CASE 
CASE SELECTION=1 
DO ADDBACK 
CASE SELECTION=2 
DO UPDTBACK 
CASE SELECTION=3 
DO DELBACK 
CASE SELECTION=4 
DO SORTBACK 
CASE SELECTION=5 
DO PACKBACK 
CASE SELECTION=6 
CLEAR 
RETURN 
ENDCASE SELECTION 
ENDDO 


* 
* 


PROCEDURE ADDBACK 

CLEAR | 

USE C:\DBASE\NATOPS\BACKSEAT 

STORE 999999999 TO ssntemp 

STORE SPACE(20) TO nametemp 

@ 2,0 TO 20,79 DOUBLE. | , 

@ 6,10 SAY "ENTER NAME OR SOCIAL SECURITY NUMBER OF NEW BACKSEAT RIDER". 

@ 8,18 SAY "ENTER LAST NAME, FI. MI. OF BACKSEAT RIDER" 

@ 11,36 SAY "- OR -" . | 

@ 13,14 SAY "ENTER SOCIAL SECURITY NUMBER OF NEW BACKSEAT RIDER" 
‘-@ 14,33 GET ssntemp PICTURE "@R ###-##4-7HHHF" 

IF nametemp<>SPACE(20) 
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SET INDEX TO C:\DBASE\NATOPS\NAMEBACK,C:\DBASE\NATOPS\SSNBACK 
GO TOP 
SEEK TRIM(nametemp) 
IF NAME=TRIM(nametemp) 
SET COLOR TO R+/B,R/W,RB 
@ 16,16 SAY "THIS BACKSEAT RIDER IS ALREADY IN THE DATABASE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W,RB 
WAIT" 
CLOSE DATABASES 
CLEAR | 
RETURN 
ENDIF 
ENDIF 
IF ssntemp<>999999999 
SET INDEX TO C:\DBASE\NATOPS\SSNBACK,C:\DBASE\NATOPS\NAMEBACK 
GO TOP 
SEEK ssntemp 
IF ssntemp=SSN 
SET COLOR TO R+/B,R/W,RB 
@ 16,16 SAY "THIS BACKSEAT RIDER IS ALREADY IN THE DATABASE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W,RB 
WAIT" 
CLOSE DATABASES 
CLEAR 


ENDIF 
IF (ssntemp=999999999 .AND. nametemp=SPACE(20)) 

SET COLOR TO R+/B,R/W,RB 

@ 16,31 SAY "NO ENTRY WAS MADE" 

@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 

SET COLOR TO W+/B,R/W,RB 

WAIT" | 

‘CLOSE DATABASES ° 

CLEAR 

RETURN 
ENDIF 
SET FORMAT TO C:\DBASE\NATOPS\BACKSEAT 
SET MESSAGE TO "WHEN NEW RECORD ENTRIES ARE COMPLETE PRESS CTRL-END" 
APPEND 
SET MESSAGE TO "" 
CLOSE DATABASES 
CLEAR 
RETURN 
* 
* 


PROCEDURE UPDTBACK 
CLEAR 
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USE C:\DBASE\NATOPS\BACKSEAT 

STORE 999999999 TO ssntemp 

STORE SPACE(20) TO nametemp 

@ 2,0 TO 20,79 DOUBLE 

@ 6,5 SAY "ENTER NAME OR SOCIAL SECURITY NUMBER OF BACKSEAT RIDER TO BE" 
@ 6,66 SAY "UPDATED" 

@ 8,18 SAY "ENTER LAST NAME, FI. MI. OF BACKSEAT RIDER" 


@ 1 36 SAY "- OR -" 
@ 13,9 SAY "ENTER SOCIAL SECURITY NUMBER OF BACKSEAT RIDER TO BE UPDATED" 
@ 14,33 GET ssntemp PICTURE "@R ##1-#H1-####" 
READ 
IF nametemp<>SPACE(20) 
SET INDEX TO C:\DBASE\NATOPS\NAMEBACK,C:\DBASE\NATOPS\SSNBACK 
GO TOP 
SEEK TRIM(nametemp) 
IF EOFQO 
SET COLOR TO R+/B,R/W,RB 
@ 16,14 SAY "THIS BACKSEAT RIDER DOES NOT EXIST IN THE DATABASE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W,RB 
WAIT "" 
CLOSE DATABASES 
CLEAR — 
RETURN 
ENDIF | 
ENDIF ne 
IF ssntemp<>999999999 
SET INDEX TO C: \DBASE\NATOPS\SSNBACK, C:\DBASE\NATOPS\NAMEBACK 
GO TOP 
SEEK ssntemp 
IF EOFO 
SET COLOR TO R+/B RW. RB 
@ 16,14 SAY "THIS BACKSEAT RIDER DOES NOT EXIST IN THE DATABASE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W-/B,R/W,RB 
WAIT™ 
CLOSE DATABASES 
CLEAR | 
RETURN 
ENDIF 
ENDIF 
IF (ssntemp=999999999 .AND. nametemp=SPACE(20)) 
SET COLOR TO R+/B,R/W,RB 
@ 16,31 SAY "NO ENTRY WAS MADE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W,RB 
WAIT ™ 
CLOSE DATABASES 
CLEAR 
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RETURN 
ENDIF 
SET FORMAT TO C:\DBASE\NATOPS\BACKSEAT 
SET MESSAGE TO "WHEN UPDATED RECORD ENTRIES ARE COMPLETE PRESS CTRL-END" 
EDIT 
SET MESSAGE TO "" 
CLOSE DATABASES 
CLEAR 
RETURN 
* 
* 


PROCEDURE DELBACK 

CLEAR | 

USE C\ADBASE\NATOPS\BACKSEAT 

STORE 999999999 TO ssntemp 

STORE SPACE(20) TO nametemp 

@ 2,0 TO 20,79 DOUBLE 

@ 6,4 SAY "ENTER NAME OR SOCIAL SECURITY NUMBER OF BACKSEAT RIDER TO BE 
DELETED" 

@ 8,18 SAY "ENTER LAST NAME, FI. MI. OF BACKSEAT RIDER" 


@ 11 36 SAY "- OR -" 
@ 13,9 SAY "ENTER SOCIAL SECURITY NUMBER OF BACKSEAT RIDER TO BE DELETED" 
@ 14,33 GET ssntemp PICTURE "@R ##4-#4-4H4#" 
READ 
IF nametemp<>SPACE(20) 
SET INDEX TO C:\DBASE\NATOPS\NAMEBACK,C:\DBASE\NATOP S\SSNBACK 
GO TOP. 
SEEK TRIM(nametemp) 
IFEOFQ © 
SET COLOR TO R+/B,R/W,RB 
@ 16,14 SAY "THIS BACKSEAT RIDER DOES NOT EXIST IN THE DATABASE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W, RB- 
WAIT ™ 
CLOSE DATABASES 
CLEAR | 
RETURN 
ENDIF 
_ ENDIF 
IF ssntemp<>999999999 | 
SET INDEX TO C\ADBASE\NATOPS\SSNBACK,C:\DBASE\NATOPS\NAMEBACK 
GO TOP | 
SEEK ssntemp 
IF EOFQ . | 
SET COLOR TO R+/B,R/W,RB 
- @ 16,14 SAY "THIS BACKSEAT RIDER DOES NOT EXIST IN THE DATABASE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W,RB 
W. AIT" "t 
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CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF 
ENDIF 
IF (ssntemp=999999999 .AND. nametemp=SPACE(20)) 
SET COLOR TO R+/B,R/W,RB 
@ 16,31 SAY "NO ENTRY WAS MADE" 
@ 17,14 SAY "PRESS ANY KEY TO RETURN TO THE BACKSEAT RIDER MENU" 
SET COLOR TO W+/B,R/W,RB 
WAIT" 
CLOSE DATABASES 
CLEAR 
RETURN 
ENDIF — 
SET FORMAT TO C:\DBASE\NATOPS\BACKSEAT 
SET MESSAGE TO "TO DELETE PRESS CTRL-U, THEN CTRL-END. TO EXIT PRESS CTRL-END" 
EDIT 
SET MESSAGE TO "" 
- CLOSE DATABASES 
CLEAR 
RETURN 


* 
* 


PROCEDURE SORTBACK 

SET COLOR TO R+/B,R/W,RB 

@ 17,24 SAY "SORTING BACKSEAT RIDER DATABASE" 

SET COLOR TO W+/B,R/W,RB 

USE C\DBASE\NATOPS\BACKSEAT 

SORT ON NAME TO C:\DBASE\NATOPS\TEMPDB 

CLOSE DATABASES 

DELETE FILE C:\DBASE\NATOPS\BACKSEAT.DBF 

RENAME C:\DBASE\NATOPS\TEMPDB.DBF TO C \DBASE\NATOP S\BACKSEAT.DBF 
USE C\DBASE\NATOPS\BACKSEAT 

SET INDEX TO C\DBASE\NATOPS\NAMEBACK,C: \DBASE\NATOP S\SSNBACK 
@ 17,5 CLEAR TO 17,75 

SET COLOR TO R+/B,R/W,RB 

@ 17,16 SAY "SORTING COMPLETE - REINDEXING NATOPS DATABASE" 

SET COLOR TO W+/B,R/W,RB 

_ REINDEX | 

CLOSE DATABASES © 

CLEAR 

RETURN 


* 
*k 


PROCEDURE PACKBACK 

SET COLOR TO R+/B,R/W,RB 

@ 17,11 SAY "PACKING BACKSEAT RIDER DATABASE TO REMOVE DELETED FILES" 
SET COLOR TO W+/B,R/W,RB 

USE C:\DBASE\NATOPS\BACKSEAT 
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SET INDEX TO C\DBASE\NATOPS\NAMEBACK,C:\DBASE\NATOPS\SSNBACK 
PACK 

CLOSE DATABASES 

CLEAR 

RETURN 

* 

* 


PROCEDURE REPORTS 
DO WHILE.T. 
CLEAR 
@ 2,0 TO 20,79 DOUBLE 
@ 3,25 SAY "SAFETY OFFICE REPORT GENERATOR" 
@ 4,1 TO 4,78 DOUBLE 
@ 8,25 SAY "1. PRINT NATOPS QUAL LIST" 
@ 9,25 SAY "2. PRINT NATOPS DATABASE" 
@ 10,25 SAY "3. PRINT BACKSEAT LIST" 
@ 11,25 SAY "4. RETURN TO MAIN MENU" 
@ 13,28 SAY "PLEASE MAKE YOUR SELECTION" 
STORE 0 TO SELECTION 
@ 13,55 GET SELECTION PICTURE "9" RANGE 1,4 
READ 
DO CASE 
CASE SELECTION=1 
DO QUALLIST 
CASE SELECTION=2 
DO NATOPLST 
- CASE SELECTION=3 
DO SEATLIST 
CASE SELECTION=4 
CLEAR 
RETURN | 
ENDCASE SELECTION 
ENDDO 


* 
* 


PROCEDURE QUALLIST 

CLEAR 

STORE CTOD("01/01/00") TO NULL 

STORE CTOD(" / / ") TO OLD,NEW.NEXT 

STORE SPACE(20) TO SIGNER 

STORE SPACE(S) TO RANKS,SERVICE. 

@2,0 TO 20,79DOUBLE | 

@ 6,18 SAY "ENTER ENDING DATE OF PREVIOUS MONTH" 
@ 6,54 GET OLD FUNCTION "D" 

@ 7,18 SAY "ENTER ENDING DATE OF PRESENT MONTH" 
@ 7,54 GET NEW FUNCTION "D" 

@ 8,18 SAY "ENTER ENDING DATE OF NEXT MONTH" 

@ 8,54 GET NEXT FUNCTION "D" 

@s. 9,16 SAY "ENTER NAME OF REPORT SIGNER" 
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@ 10,16 SAY "ENTER RANK OF REPORT SIGNER" 


SET COLOR TO R+*/B,R/W,BR 
@ 13,16 SAY "ENSURE THE PRINTER IS ON AND peo LOADED" 
SET COLOR TO W+/B,R/W,BR 
@ 16,22 SAY "CONTINUE WITH PRINT JOB (Y/N)" 
STORE "" TO PROCEED | 
@ 16,52 GET PROCEED PICTURE "!" 
READ 
IF PROCEED?"Y" 
CLEAR 
RETURN TO MASTER 
ENDIF 
@ 13,5 CLEAR TO 13,75 
SET COLOR TO R+/B,R/W,BR 
@ 13,25 SAY "PRINTING NATOPS QUAL REPORT" 
SET COLOR TO W+/B,R/W,BR 
SET MESSAGE TO "IF PRINTING STOPS - PAUSE - THEN PRESS Y" 
SET CONSOLE OFF 
SET PRINT ON 
2?CHR(27)+"x"+"1" 
_ SET PRINT OFF 
@ 0,0 
SET DEVICE TO PRINTER 
@0,0SAY"" 
@ 0,66 SAY DAY(DATEQ) 
@ 0,70 SAY UPPER(LEFT(CMONTH(DATEQ),3)) 
@ 0,74 SAY RIGHT(DTOC(DATEO),2) 
SET PRINT ON 
??CHR(27)+"E" 
SET PRINT OFF 
@ 2,9 SAY "MEMORANDUM" 
SET PRINT ON 
?2?CHR(27)+'"F" 
SET PRINT OFF 
@ 4,9 SAY "From: NATOPS Officer, Strike’ Fighter Squadron ONE TWO FIVE" 
@5,9 SAY "To: All Squadron Aircrew" 
@ 6,9 SAY "Via: Operations Officer, Strike Fighter Squadron ONE TWO FIVE" 
@ 8,9 SAY "Subj: NATOPS QUAL EXPIRATION DATES FOR" 
@ 8,48 SAY UPPER(CMONTH(NEW)) 
@ 8,PCOLO SAY "/" 
@ 8,PCOLO SAY UPPER(CMONTH(NEXT)) 
@ 10,9 SAY "Ref: (a) OPNAVINST 3710.7P" 
STORE .T. TO PARAGRAF 
STORE .F. TO SPACING 
STORE 11 TOx 
STORE 1 TOy 
DO WHILE (x>=11 .AND. x<20) | 


75 











USE C:’\DBASE\NATOPS\NATOPS 
IF x=17 
STORE 18 TO x 
ENDIF _ 
STORE FIELD(x) TO z 
SORT TO C\DBASE\NATOPS\TEMP ON GRADE/D,NAME FOR (&z<=OLD .AND. &2>NULL) 
USE C:\DBASE\NATOPS\TEMP 
IF RECCOUNTQ>=1 
IF PARAGRAF 
@ PROW()+2,9 SAY STR(y,1)+". As per reference (a), the ne 
@ PROW(Q,PCOL(+1 SAY "qualifications have" 
@ PROWO(+1,9 SAY "expired:" 
SET PRINT ON 
?2?CHR(27)+"E" 
SET PRINT OFF 
@ PROW()+2,9 SAY "Name" 
@ PROW(,35 SAY "Rank" 
@ PROW(O,50 SAY "Qual" 
@ PROW(O,67 SAY "Date" 
SET PRINT ON 
2??CHR(27)+"F" 
‘SET PRINT OFF 
@ PROWO0+1,9 SAY REPLICATE("-",65) 
STORE y+1 TO y 
STORE .F. TO PARAGRAF 
ENDIF 
IF SPACING 
@ PROW()+1,10 SAY "" 
ELSE 
STORE .T. TO SPACING 
ENDIF 
DO WHILE .NOT. EOFO 
@ PROW(Q+1,9 SAY NAME 
@ PROW(,35 SAY RANK 
@ PROW(,48 SAY FIELD(x) 
@ PROW(O,65 SAY &Z, 
SKIP 
IF PROW()>=53 
EJECT 
ENDIF 
ENDDO 
ENDIF 
IF (x=19 .AND. .NOT. PARAGRAF) 
@ PROW(+1,9 SAY REPLICATE("-",65) 
ENDIF 
STORE x+1 TO x 
ENDDO | 
STORE .T. TO PARAGRAF 
STORE .F. TO SPACING 
STORE 11 TO x 
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DO WHILE (x>=11 .AND. x<20) 
USE C:’\DBASE\NATOPS\NATOPS 
IF x=17 
STORE 18 TO x 
ENDIF 
STORE FIELD(x) TO z 
SORT TO C:\DBASE\NATOPS\TEMP ON GRADE/D,NAME FOR (&z<=NEW .AND. &z>OLD) 
USE CADBASE\NATOPS\TEMP 
IF RECCOUNT()>=1 
IF PARAGRAF 
IF PROWQ>=50 
EJECT 
ENDIF 
@ PROW(+2,9 SAY STR(y,1)+". As per reference (a), the following" 
@ PROWO,PCOLO+1 SAY "qualifications expire" 
@ PROWO+1,9 SAY "during the month of" 
@ PROWO,PCOLO+1 SAY CMONTH(NEW) 
@ PROW(),PCOLO SAY ":" 
SET PRINT ON 
22CHR(27)+"E" 
SET PRINT OFF 
@ PROW(0+2,9 SAY "Name" 
@ PROW(,35 SAY "Rank" 
@ PROW(,50 SAY "Qual" 
@ PROW(,67 SAY "Date" 
SET PRINT ON 
??CHR(27)+"F" 
SET PRINT OFF 
@ PROWO0+1,9 SAY REPLICATE("-",65) 
STORE y+1 ‘TO y 
STORE FF. TO PARAGRAF . 
ENDIF » ' 
IF SPACING 
@ PROWO+1,10 SAY "" 
ELSE 
STORE .T. TO SPACING 
ENDIF 
DO WHILE .NOT. EOFQO 
@ PROWO+1,9 SAY NAME 
@ PROWO,35 SAY RANK 
@ PROW(O,48 SAY FIELD(x) 
@ PROW(O,65 SAY &z 
SKIP 
IF PROWQ>=53 
EJECT 
ENDIF 
ENDDO 
ENDIF 
IF (x=19 AND. .NOT. PARAGRAF) 
@ PROWO+1,9 SAY REPLICATE("-",65) 
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ENDIF 
STORE xt+1 TO x 
ENDDO 
STORE .T. TO PARAGRAF 
STORE .F. TO SPACING 
STORE 11 TO x 
DO WHILE (x>=11 .AND. x<20) 
USE C:\DBASE\NATOPS\NATOPS 
IF x=17 
STORE 18 TO x 
ENDIF 
STORE FIELD(x) TO z 
SORT TO C:\DBASE\NATOPS\TEMP ON GRADE/D,NAME FOR (&z<=NEXT .AND. &z>NEW) 
USE C\DBASE\NATOPS\TEMP 
IF RECCOUNTQO>=1 
IF PARAGRAF 
TIF PROWQ>=50 
EJECT 
ENDIF 
@ PROW0+2,9 SAY STR(y,1)+". As per reference (a), the following" 
@ PROWO,PCOLO+1 SAY "qualifications expire" 
@ PROWO+1,9 SAY “during the month of" 
@ PROW(,PCOLO+1 SAY CMONTH(NEXT) 
@ PROWOQ,PCOLO SAY ":" 
SET PRINT ON 
2??CHR(27)+"E" 
SET PRINT OFF 
@ PROW()+2,9 SAY "Name" 
@ PROWO(O,35 SAY "Rank" 
@ PROWO(O,50 SAY "Qual" 
@ PROW(O,67 SAY "Date" 
SET PRINT ON 
??CHR(27)+"F" 
SET PRINT OFF 
@ PROWO(+1,9 SAY REPLICATE("-",65) 
STORE y+1 TO y 
STORE .F. TO PARAGRAF 
ENDIF 
IF SPACING 
@ PROWO(0+1,10 SAY "" 
ELSE 
STORE .T. TO SPACING 
ENDIF 
DO WHILE .NOT. EOFO 
@ PROW(+1,9 SAY NAME 
@ PROWO,35 SAY RANK 
@ PROW(O,48 SAY FIELD(x) 
@ PROW(O,65 SAY &z 
SKIP 
IF PROWQ>=53 
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EJECT 
ENDIF 
ENDDO 
ENDIF 
IF (x=19 AND. NOT. PARAGRAF) 
@ PROW(++1,9 SAY REPLICATE("-",65) 
ENDIF 
STORE x+1 TO x 
ENDDO Seesaw 
@PROW(0+4,41 SAY TRIM(SIGNER) 
@PROW(t1,41 SAY TRIM(RANKS) 
STORE LEN(TRIM(SIGNER))-(LEN(TRIM(RANKS))+LEN(TRIM(SERVICE))) TO s 
@ PROW(,PCOL()+s SAY TRIM(SERVICE) 
@ PROW(02,9 SAY "DISTRIBUTION LIST:" 
@ PROW(t+1,9 SAY "CO/KO" 
@ PROW(#1,9 SAY "OPS" 
@ PROW(+1,9 SAY "SCHEDULES" 
@ PROW(+1,9 SAY "TRAINING" 
@ PROW(+1,9 SAY "READY ROOM" 
@ PROW(+1,9 SAY "STRKFIGHTWINGPAC" 
@ PROW(?+1,9 SAY "STRKFIGHTWPNSCHOLPAC" 
EJECT 
SET PRINT ON 
22CHR(27)+"x"+"0" 
SET PRINT OFF 
SET DEVICE TO SCREEN 
SET CONSOLE ON 
SET MESSAGE TO "" 
CLOSE DATABASES 
DELETE FILE C:\DBASE\NATOPS\TEMP. DBF 
CLEAR 
RETURN TO MASTER 


* 
PROCEDURE NATOPLST 
SET COLOR TO R+/B,R/W,RB 
@ 17,23 SAY "PRINTING NATOPS DATABASE LIST" 
SET COLOR TO W+/BR/WRB 
SET MESSAGE TO "IF PRINTING STOPS - PAUSE - THEN PRESS Y" 
SET CONSOLE OFF 
SET PRINT ON 
22CHR(27)+"x"+"0" 
22CHR(27)+"M" 
SET PRINT OFF 
@ 0,0 
SET DEVICE TO PRINTER 
@0,0 SAY" | 
@ 0,89 SAY DAY(DATE() 
@ 0,93 SAY UPPER(LEFT(CMONTH(DATE(),3)) 
@ 0,97 SAY RIGHT(DTOC(DATEO),2) 
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SET PRINT ON 
??CHR(27)+"E" 
SET PRINT OFF 
@ 2,39 SAY "MASTER NATOPS ROSTER" 
@ 4,33 SAY "INST" 
@ 4,62 SAY "F/A-18" 
@ 4,72 SAY "F/A-18" 
@ 4,83 SAY "T-34" 
@ 4,93 SAY "T-34" 
@ 5,1 SAY "NAME" 
@ 5,22 SAY "UPCHIT" 
@ 5,33 SAY "CHECK" 
@5,43 SAY "PHYS" - 
@ 5,53 SAY "SWIM" 
@ 5,62 SAY "NATOPS" 
@ 5,73 SAY "SEAT" 
@ 5,82 SAY "NATOPS" 
@ 5,92 SAY "EGRESS" 
SET PRINT ON 
?2?CHR(27)+"F" 
SET PRINT OFF 
USE C:\DBASE\NATOPS\NATOPS 
DO WHILE .NOT. EOF( » 
STORE SUBSTR(NAME,1,18) TO names 
@ PROW(+1,1 SAY names 
@ PROW(,21 SAY UPCHIT 
@ PROW(,31 SAY INSTCHECK 
@ PROW(),,41 SAY PHYSIOLOGY 
@ PROW(O,51 SAY SWIM 
@ PROW(),61 SAY FI8NATOPS 
@ PROW(),71 SAY FI8SEAT | 
@ PROW(),81 SAY T34NATOPS 
@ PROW(,91 SAY T34EGRESS 
IF PROWQ>=55. 
EJECT . 
SET PRINTON | 
?2?CHR(27)+"E" 
SET PRINT OFF 
@ PROW(O,35 SAY "INST" 
@ PROW(,64 SAY "F/A-18" 
@ PROW(,74 SAY "F/A-18" 
@ PROW(,85 SAY "T-34" 
~ @PROW(O,95 SAY "T-34" 
@ PROW()+1,1 SAY "NAME" 
@ PROW(O,22 SAY "UPCHIT" 
@ PROWO,33 SAY "CHECK" 
@ PROW(,43 SAY "PHYS" 
@ PROWO(O,53 SAY "SWIM" 
@ PROWO,62 SAY "NATOPS" ~~ 
@ PROW0(,73 SAY "SEAT" 
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@ PROW(,82 SAY "NATOPS" 
@ PROW(,92 SAY "EGRESS" 
SET PRINT ON 
22CHR(27)+"F" 
SET PRINT OFF 
ENDIF 


SET PRINT ON 
2?CHR(27)+"P" 

SET PRINT OFF 

SET DEVICE TO SCREEN 

SET CONSOLE ON 

SET MESSAGE TO "" 

CLOSE DATABASES 

CLEAR 

RETURN TO MASTER 

* 


* 


PROCEDURE SEATLIST 

STORE SPACE(20) TO SIGNER 

STORE SPACE(5) TO RANKS,SERVE 

@ 17,10 SAY "ENTER NAME, RANK AND SERVICE OF BACKSEAT RIDER LIST SIGNER" 
@ 18,10 SAY "NAME" 

@ 18,15 GET SIGNER PICTURE "U1!!! 11 11114" 

@ 18,39 SAY "RANK" 


READ 
@ 17,5 CLEAR TO 18,75 
SET COLOR TO R+/B;R/W,RB 
@ 17,28 SAY "PRINTING BACKSEAT LIST" 
SET COLOR TO W+/B,R/W.RB 
SET MESSAGE TO "IF PRINTING STOPS - PAUSE - THEN PRESS Y" 
SET CONSOLE OFF 
SET PRINT ON 
22CHR(27)4"x"-4"1" 
22CHR(27)+"M" 
SET PRINT OFF 
@0,0 
SET DEVICE TO PRINTER 
@0,0SAY"". — 
@ 0,82 SAY DAY(DATEQ) 
@ 0,86 SAY UPPER(LEFT(CMONTHDATE(),3)) 
@ 0,90 SAY RIGHT@TOCDATEO), 2) 
SET PRINT ON 
22CHR(27)+"E" 
SET PRINT OFF _ 
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@ 2,11 SAY "MEMORANDUM" 
SET PRINT ON 
2??CHR(27)+"F" 
SET PRINT OFF 
@ 4,11 SAY "From: NATOPS Officer, Strike Fighter Squadron ONE TWO FIVE" 
@5,11 SAY "To: Operations Officer, Strike Fighter Squadron ONE TWO FIVE" 
@ 6,11 SAY "Info: CDO/ODO/SDO/Schedules Officer" 
@ 8,11 SAY “Subj: AERONAUTICALLY/NONAERONAUTICALLY DESIGNATED BACKSEAT 
RIDER" 
@ 8,76 SAY "LIST" 
@ 10,11 SAY "Ref: (a) VFA-125INST 3710.4D" 
@ 11,17 SAY "(b) OPNAVINST 3710.7P" 
@ 13,11 SAY "1. As outlined in ref (a), the listed aeronautically designated" 
@ 13,75 SAY "personnel may" 
@ 14,11 SAY "occupy the aft seat of VFA-125 aircraft with the" 
@ 14,60 SAY "following restrictions:" 
@ 16,17 SAY "A. Only qualified IPs will be selected to conduct backseat rider” 
@ 17,20 SAY "proficiency and incentive flights.” 
@ 18,17 SAY "B. No backseat riders in PMCF or in-flight refueling flights." 
@ 19,17 SAY "C. Aeronautically designated personnel may fly in the aft cockpit" 
@ 19,83 SAY "ofthe" 
@ 20,20 SAY "following flights:" 
@ 21,20 SAY "(1) All Transition Phase flights FORM, NAV, AWI) and VIDs." 
@ 22,20 SAY "(2) BFM and LAT flights with the IP's approval." 
@ 23,20 SAY "(3) FWT and STRIKE sorties with Phase Head authorization." 
@ 24,20 SAY "(4) CV flights with CO's or OPS Officer approval." 
@ 25,20 SAY "(5) GUN Stage flights." 
@ 27,11 SAY "2. The following personnel are" 
SET PRINT ON 
2?CHR(27)+"E" 
SET PRINT OFF 
@ 27,42 SAY "AERONAUTICALLY DESIGNATED" 
SET PRINT ON 
22?CHR(27)+"F" 
SET PRINT OFF 
@ 27,68 SAY "Backseat Riders in" 
@ 28,11 SAY "accordance with ref (b)." 
USE C \DBASE\NATOPS\BACKSEAT 
GO TOP 
DO WHILE .NOT. EOFQ 
STORE 15 TO x 
DO WHILE (x>14 .AND. x<19) 
STORE FIELD(x) TO y 
IF (&y<DATEO) 
REPLACE OUTOFQUAL WITH.T. 
ENDIF 
STORE x+1 TO x 
ENDDO 
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SORT TO C:\DBASE\NATOPS\TEMP ON GRADE/D,NAME FOR .NOT. OUTOFQUAL AND. 
AERODESIG 
USE C:\DBASE\NATOPS\TEMP 
IF RECCOUNT()>=1 
SET PRINT ON 
22?CHR(27)+"E" 
SET PRINT OFF 
@ 30,38 SAY "RANK" 
@ 30,51 SAY "QU 
@ 30,65 SAY "QUAL" 
@ 30,79 SAY "RIDER" 
@ 31,14 SAY "NAME" 
@ 31,38 SAY "RATE" 
@ 31,49 SAY "EXPIRING" 
@ 31,63 SAY "EXP DATE" _ 
@ 31,78 SAY "LOCATION" 
SET PRINT ON 
29CHR(27)+"E" 
SET PRINT OFF 
DO WHILE .NOT. EOF() 
- IF PROWQ>=55 
EJECT 
ENDIF 
@ PROW(+1,14 SAY NAME 
IF OFFICER 
@ PROW(,38 SAY RANK 
ENDIF 
IF ENLISTED 
@ PROW(,38 SAY RATE 
ENDIF 
STORE 15 TOx 
STORE CTOD("12/31/99") TO NULL 
DO WHILE (x>14 .AND. x<19) 
STORE FIELD(x) TO y 
IF (&y<NULL) 
STORE &y TO NULL 
STORE x TO z 
ENDIF ee 
STORE x+1 TO x 
ENDDO 
@ PROW(,49 SAY FIELD(z) 
@ PROWO0,63 SAY NULL ~ 
@ PROWO,78 SAY LOCATION 


IF PROWQ>=40 
EJECT 
ENDIF 
@ PROW(0+2,11 SAY "3. As outlined in ref (a), the listed non-aeronautically" 
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@ PROW(),68 SAY "designated personnel may" 
@ PROWO0+1,11 SAY "occupy the aft seat of VFA-125 aircraft with" 
@ PROW(O,56 SAY "the following restrictions:" 
@ PROW()+2,17 SAY "A. Only qualified IPs will be selected to conduct backseat" 
@ PROWO,76 SAY “rider" 
@ PROW()+1,20 SAY "proficiency and incentive flights." 
@ PROW(+1,17 SAY "B. No backseat riders in PMCF or in-flight refueling" 
@ PROW(,70 SAY "flights." 
@ PROW0+1,17 SAY "C. Flights are limited to Transition Phase (F ORM/NAV/AW])" 
@ PROW(,75 SAY "and VID." 
@ PROW()+1,17 SAY "D. Non-aeronautically designated personnel may not fly in" 
@ PROW(,75 SAY "the aft cockpit" | 
@ PROW(+1,20 SAY "of the following flights:" 
@ PROW(0+1,20 SAY "(1) Night flights." 
@ PROW(+1,20 SAY "(2) Flights when the field is IFR." 
@ PROWO+1,20 SAY "(3) Flights to or from the CV." 
@ PROW()+1,20 SAY "(4) Flights that do not begin/end at the same field." 
@ PROW(+2,11 SAY "4. The following personnel are" 
SET PRINT ON 
2??CHR(27)+"E" 
SET PRINT OFF 
@ PROW(O,42 SAY "NON-AERONAUTICALLY DESIGNATED" 
SET PRINT ON 
2??CHR(27)+"F" 
SET PRINT OFF 
@ PROW(O,72 SAY "Backseat Riders in" 
@ PROWO0+1,11 SAY "accordance with ref (b)." 
USE C:\DBASE\NATOPS\BACKSEAT 
SORT TO C\DBASE\NATOPS\TEMP ON GRADE/D,NAME FOR .NOT. OUTOFQUAL .AND. .NOT.: 
AERODESIG 
USE C:\DBASE\NATOPS\TEMP | | 
IF RECCOUNTQ>=1 
SET PRINT ON 
?2?CHR(27)+"E" 
SET PRINT OFF 
@ PROW(0+2,38 SAY "RANK/" 
@ PROW(O,51 SAY "QUAL" 
@ PROW(O,65 SAY "QU 
@ PROW(,79 SAY "RIDER" 
@ PROW(+1,14 SAY "NAME" 
@ PROWO,38 SAY "RATE" | 
@ PROW(,49 SAY "EXPIRING" 
@ PROW(,63 SAY "EXP DATE" 
@ PROW(O,78 SAY "LOCATION" 
SET PRINT ON 
2?2?CHR(27)+"F" 
SET PRINT OFF 
DO WHILE .NOT. EOFO 
_IF PROWQ>=55 
EJECT 
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ENDIF | 
@ PROWO+1,14 SAY NAME 
IF OFFICER 
@ PROWO,38 SAY RANK 
ENDIF 
IF ENLISTED 
@ PROW(O,38 SAY RATE 
ENDIF 
STORE 15 TO x 
STORE CTOD("12/31/99") TO NULL 
DO WHILE (x>14 .AND. x<19) 
STORE FIELD(x) TO y 
IF (&y<NULL) 
STORE &y TO NULL 
STORE x TO z 
ENDIF 
STORE x+1 TO x 
ENDDO 
@ PROW(O,49 SAY FIELD(z) 
@ PROW(O,63 SAY NULL 
@ PROW(,78 SAY LOCATION 


@PROW(+4,50 SAY TRIM(SIGNER) 
@ PROW()+1,50 SAY TRIM(RANKS) 
STORE LEN(TRIM(SIGNER))-(LEN(TRIM(RANKS))+LEN(TRIM(SERVE))) TO s 
@ PROW() eos SAY TRIM(SERVE) 
EJECT 
SET PRINT ON 
22CHR(27)+"x"-4"0" 
22CHR(27)+"P" 
SET PRINT OFF 
SET DEVICE TO SCREEN 
SET CONSOLE ON 
SET MESSAGE TO "" 
CLOSE DATABASES 
DELETE FILE C:’\DBASE\NATOPS\TEMP.DBF 
CLEAR 
. RETURN TO MASTER 


* 
' Ok 
PROCEDURE BACKUPS 
IF backitup="" 
USE C: \DBASE\NATOPS\UTILITY 
STORE (DATEQ-BACKDATE) TO lastbackup 
CLOSE DATABASES 
IF lastbackup>=3 
STORE "" TO backitup 
SET COLOR TO R+/B,R/W,BR 
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@ 18,12 SAY "IT HAS BEEN "+STR(astbackup,2)+" DAYS SINCE THE DATABASES"+. 
" WERE BACKED UP" 
@ 19,8 SAY "WOULD YOU LIKE TO BACK UP THE DATABASES AT THIS TIME (Y/N)?" 
@ 19,68 GET backitup PICTURE "!" 
SET COLOR TO W+/B,R/W.BR 
READ 
ENDIF 
ENDIF 
IF backitup="Y" 
CLEAR 
@ 2,0 TO 20,79 DOUBLE 
@ 3,28 SAY "DATABASE BACKUP PROGRAM" 
@ 4,1 TO 4,78 DOUBLE 
SET COLOR TO R+*/B,R/W.BR 3 
@ 6,15 SAY "PLACE THE SAFET Y/NATOPS DATABASE DISK IN DRIVE A" 
SET COLOR TO WHB,R/W.BR | 
@ 8,19 SAY "CONTINUE WITH DATABASE BACKUP? (Y/N)" 
STORE""TO CHOICE ~ 
@ 8,57 GET CHOICE PICTURE "!" 
READ 
IF CHOICE="Y" 
@ 6,5 CLEAR TO 8,75 
@ 7,13 SAY "COPYING NATOPS.DBF" 
COPY FILE C:\DBASE\NATOPS\NATOPS.DBF TO A: \NATOPS. DBF 
@ 8,13 SAY "COPYING NAMEINDX.NDX" 
COPY FILE C:\DBASE\NATOPS\NAMEINDX.NDX TO A:\NAMEINDX.NDX 
@ 9,13 SAY "COPYING SSNINDEX.NDX" | 
COPY FILE C:\DBASE\NATOPS\SSNINDEX.NDX TO A:\SSNINDEX. NDX 
@ 7,48 SAY "COPYING BACKSEAT DBE" 
COPY FILE C:\DBASE\NATOPS\BACKSEAT.DBF TO A:\BACKSEAT.DBF 
@ 8,48 SAY "COPYING NAMEBACK.NDX" | 
_ COPY FILE C:\DBASE\NATOPS\NAMEBACK NDX TO A:\NAMEBACK.NDX 
@ 9,48 SAY "COPYING SSNBACK.NDX" 
COPY FILE C:\DBASE\NATOPS\SSNBACK.NDX TO A: \SSNBACK. NDX 
USE C:\DBASE\NATOPS\UTILITY 
REPLACE BACKDATE WITH DATEQ) 
CLOSE DATABASES | 
@ 14,48 SAY "COPYING UTILITY.DBE" 
COPY FILE C:\DBASE\NATOPS\UTILITY.DBF TO A:\UTILITY.DBF 
@ 16,18 SAY "BACKUP COMPLETE. PRESS ANY KEY TO CONTINUE" 
- WAIT-*". - 
- ENDIF 
ENDIF = 
CLEAR : 
RETURN 
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